Date: Mon, 6 Feb 2023 17:23:34 -0800 From: Rick Macklem <rick.macklem@gmail.com> To: FreeBSD CURRENT <freebsd-current@freebsd.org> Cc: Konstantin Belousov <kib@freebsd.org>, Alan Somers <asomers@freebsd.org> Subject: RFC: Should fspacectl() commit changes to stable storage? Message-ID: <CAM5tNy6Dkv==TceNF5n02wY20-rEAgn_8S%2BtKNwv6iia1qqLYA@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAM5tNy6Dkv==TceNF5n02wY20-rEAgn_8S%2BtKNwv6iia1qqLYA>