On Mon, 6 Jan 2020 at 10:16, Dave Chinner <david@xxxxxxxxxxxxx> wrote: > > Hence AIO_FSYNC and now chained operations in io_uring to allow > fsync to be issues asynchronously and be used as a "write barrier" > between groups of order dependent IOs... Thanks for detailing this. > > 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... Ah! > > 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... Jan mentions this over on https://youtu.be/-oP2BOsMpdo?t=6268 . Basically he advises against hole punching if you're going to write to that area again because it fragments the file, hurts future performance etc. But I guess if you were using FALLOC_FL_ZERO_RANGE no hole is punched (so no fragmentation) and you likely get faster reads of that area until the data is rewritten too. Are areas that have had FALLOC_FL_ZERO_RANGE run on them eligible for trimming if someone goes on to do a background trim (Jan - doesn't this sound like the best of both both worlds)? My question is what happens if you call FALLOC_FL_ZERO_RANGE and your filesystem is too dumb to mark extents unwritten - will it literally go away and write a bunch of zeros over that region and your disk is a slow HDD or will that call just fail? It's almost like you need something that can tell you if FALLOC_FL_ZERO_RANGE is efficient... -- Sitsofe | http://sucs.org/~sits/
