On Mon 06-01-20 21:15:18, Dave Chinner wrote: > On Mon, Jan 06, 2020 at 07:24:53AM +0000, Sitsofe Wheeler wrote: > > For 3. it sounded like Jan Kara was saying there wasn't anything at > > the moment (hypothetically you could introduce a call that marked the > > extents as "unwritten" but it doesn't sound like you can do that > > You can do that with fallocate() - FALLOC_FL_ZERO_RANGE will mark > the unused range as unwritten in XFS, or you can just punch a hole > to free the unused space with FALLOC_FL_PUNCH_HOLE... Yes, this works for ext4 the same way. > > today) and even if you wanted to use something like TRIM it wouldn't > > be worth it unless you were trimming a large (gigabytes) amount of > > data (https://youtu.be/-oP2BOsMpdo?t=6330 ). > > Punch the space out, then run a periodic background fstrim so the > filesystem can issue efficient TRIM commands over free space... Yes, in that particular case Richard was mentioning with Sqlite, he was asking about a situation where he has a DB file which has 64k free here, 256k free there and whether it helps the OS in any way to tell that these areas are free (but will likely get reused in the future). And in this case I told him that punching out the free space is going to do more harm than good (due to fragmentation) and using FALLOC_FL_ZERO_RANGE isn't going to bring any benefit to the filesystem or the storage. He was also wondering whether using TRIM for these free areas on disk is useful and I told him that for current devices I don't think it will bring any benefit with the sizes he is talking about. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
