fallocate(FALLOC_FL_PUNCH_HOLE)

[Richard Laager <rlaager@xxxxxxxxxx>]

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

Attachment: signature.asc
Description: This is a digitally signed message part