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