Re: fallocate(FALLOC_FL_PUNCH_HOLE)

[Ted Ts'o <tytso@mit.edu>]

On Wed, Mar 14, 2012 at 02:27:09PM +1100, Dave Chinner wrote:
> > If the answer to #2 is not C, it would appear there's no atomic way to
> > indicate that I'm done with certain data* but I want the filesystem to
> > continue to guarantee space for me. Is this correct?
> 
> Not through fallocate() right now. XFS has an ioctl that will turn
> written ranges and holes back into preallocated space:
> XFS_IOC_ZERO_RANGE.  I've got a patch that introduces this zeroing
> capability to fallocate (see below) which currently works on XFS.

If this is something that an important application or set of
applications really want, maybe we should provide an interface through
fallocate(2) TO DO THIS.

> > * so the filesystem can send a TRIM/UNMAP to an underlying SSD.
> 
> It does not, however, issue discards on the range, because it is
> still allocated space in the filesystem. It could probably be
> made to do so, especially as the folks that requested the
> XFS_IOC_ZERO_RANGE functionality asking about extending it to do
> this last week.

... and if we know that discards will persistently cause blocks to
return zero (the device exports a flag indicating whether this is
true), and that trims are fast (i.e., they export the SATA 3.1 queable
trim command), it might make sense to simply issue a discard on the
range and not even mess with the metadata flags (since messing with
the metadata flags has overhead at punch time and the next time oyu
want to write to that block).

The choice of what to do should be hidden from the application, though
and be handled at the file system level.

						- Ted