On Mon, Feb 6, 2023 at 6:23 PM Rick Macklem <rick.mack...@gmail.com> wrote: > > PR#269328 reports an issue related to fspacectl() being > mixed with mmap'd I/O. > > When working on a fix for this for the NFS client, I realized that > "man fspacectl" does not clarify if the deallocation should commit > changes to stable storage before returning success. > vop_stddeallocate() currently does not do this so, if a machine > crashes immediately after fspacectl() returns success, the hole > may not be there when the machine reboots. > > For POSIX writes, it is clear that recently written data may be > lost when a machine crashes/reboots and fsync(2) is used to > ensure the data is on stable storage and won't be lost when a > crash/reboot occurs. > > The question is "Should fsync(2) be required to ensure a hole > punched by fspacectl(2) is not lost or should it be guaranteed > to not be lost when fspacectl(2) returns? > Since fspacectl(2) is FreeBSD specific and there is no standard, > it could be defined either way. > > So, what do you think? rick
It think it should be just like write. An fsync should be required to ensure that the effects will be visible after a reboot.
