fallocate(FALLOC_FL_PUNCH_HOLE)

[Richard Laager]

I've been working on a discard patch for QEMU.

I have a couple of questions about the semantics of fallocate()'s
FALLOC_FL_PUNCH_HOLE that are not addressed in the latest man-pages.git.

1. Upon successful return, are the results guaranteed to be on
stable storage?
1. If not, is fdatasync() sufficient, or is fsync()
required?
2. Does O_DSYNC on open() change any of this?
3. Does O_DIRECT on open() change any of this?
2. If I punch a hole in a previously preallocated range, is this...
A. required to undo the preallocation?
B. permitted, but not required, to undo the preallocation?
C. forbidden from undoing the preallocation?

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?

* so the filesystem can send a TRIM/UNMAP to an underlying SSD.

Thanks,
Richard

[Dave Chinner]

Post by Richard Laager
I've been working on a discard patch for QEMU.
I have a couple of questions about the semantics of fallocate()'s
FALLOC_FL_PUNCH_HOLE that are not addressed in the latest man-pages.git.
1. Upon successful return, are the results guaranteed to be on
stable storage?

No.

Post by Richard Laager
1. If not, is fdatasync() sufficient, or is fsync()
required?

Will be on stable storage before fdatasync() returns.

Post by Richard Laager
2. Does O_DSYNC on open() change any of this?

Will be on stable storage before fallocate() returns.

Post by Richard Laager
3. Does O_DIRECT on open() change any of this?

Has no effect on behaviour.

Post by Richard Laager
2. If I punch a hole in a previously preallocated range, is this...
A. required to undo the preallocation?
B. permitted, but not required, to undo the preallocation?
C. forbidden from undoing the preallocation?

B. Most implementations will give you A, though.

Post by Richard Laager
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.

Post by Richard Laager
* 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.

Cheers,

Dave.
--
Dave Chinner
***@fromorbit.com

fs: Introduce FALLOC_FL_ZERO_RANGE

From: Dave Chinner <***@redhat.com>

FALLOC_FL_ZERO_RANGE is the equivalent of an atomic hole-punch +
preallocation. It enabled ranges of written data to be turned into
zeroes without requiring IO or having to free and reallocate the
extents in the range given as would occur if we had to punch and
then preallocate them separately. This enables applications to zero
parts of files very quickly without changing the layout of the files
in any way.

Signed-off-by: Dave Chinner <***@redhat.com>

---
fs/xfs/xfs_file.c | 6 +++++-
include/linux/falloc.h | 1 +
2 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c
index 825390e..ce2fd17 100644
--- a/fs/xfs/xfs_file.c
+++ b/fs/xfs/xfs_file.c
@@ -912,7 +912,9 @@ xfs_file_fallocate(
int cmd = XFS_IOC_RESVSP;
int attr_flags = XFS_ATTR_NOLOCK;

- if (mode & ~(FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE))
+ if (mode & ~(FALLOC_FL_KEEP_SIZE |
+ FALLOC_FL_PUNCH_HOLE |
+ FALLOC_FL_ZERO_RANGE))
return -EOPNOTSUPP;

bf.l_whence = 0;
@@ -923,6 +925,8 @@ xfs_file_fallocate(

if (mode & FALLOC_FL_PUNCH_HOLE)
cmd = XFS_IOC_UNRESVSP;
+ else if (mode & FALLOC_FL_ZERO_RANGE)
+ cmd = XFS_IOC_ZERO_RANGE;

/* check the new inode size is valid before allocating */
if (!(mode & FALLOC_FL_KEEP_SIZE) &&
diff --git a/include/linux/falloc.h b/include/linux/falloc.h
index 73e0b62..9160c70 100644
--- a/include/linux/falloc.h
+++ b/include/linux/falloc.h
@@ -3,6 +3,7 @@

#define FALLOC_FL_KEEP_SIZE 0x01 /* default is extend size */
#define FALLOC_FL_PUNCH_HOLE 0x02 /* de-allocates range */
+#define FALLOC_FL_ZERO_RANGE 0x04 /* zero/prealloc all blocks in range */

#ifdef __KERNEL__

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Richard Laager]

Post by Dave Chinner

Post by Richard Laager
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
XFS_IOC_ZERO_RANGE.

Do filesystems generally track the data necessary to tell the difference
between fallocate() + write() and just a regular write()? If so, it
might be nice for applications to be able to say "I'm done with this
data" and effectively "undo" the write(). In other words, the space
would return to being unallocated or preallocated, whichever it was
originally.

I suspect they don't track preallocation of data ranges once they're
filled with data. So, for example, QEMU will have to be told whether the
administrator wants thin (i.e. use PUNCH_HOLE) or thick (i.e. use
ZERO_RANGE) provisioning.

[Ted Ts'o]

Post by Dave Chinner

Post by Richard Laager
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
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.

Post by Dave Chinner

Post by Richard Laager
* 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
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html