On Mon, 2019-05-06 at 11:53 -0700, Paul Eggert wrote: > On 5/6/19 5:05 AM, Florian Weimer wrote: > > > I've been told that on Linux, close does not report writeback errors. > > So the only way to get a reliable error indicator (beyond what you get > > from the write system call) would be fsync. > > Are you sure you asked your expert the right question? I just looked at > the current (5.1) Linux kernel, and though I'm no kernel expert it looks > like the close system call invokes filp_close, which calls > filp->f_op->flush which on NFS is nfs_file_flush, which invokes > vfs_fsync which in turn invokes nfs_file_fsync, and surely this does > what fsync would do (and does more work and error checking than an > ordinary write syscall would do, at any rate). >
Sure, we have the plumbing to report errors there and some filesystems do it, but those errors don't mean much. See below. > Admittedly Linux is a real mess in reporting write errors back to the > user, and this has been true for years.[1] That being said, the > longstanding documented tradition is that writeback errors are reported > in later close or fsync calls, and there are suggestions to clean up > this kernel area to get closer to doing what the documentation says.[2] > So until we're pretty sure the matter is settled for Linux, perhaps we'd > better let Gnulib be. > > [1] Gunawi HS, Rubio-González C, Arpaci-Dusseau AC, Arpaci-Dusseau RH, > Liblit B. EIO: Error Handling is Occasionally Correct. FAST 2008. > https://www.usenix.org/legacy/event/fast08/tech/gunawi.html > > [2] Edge J. Handling writeback errors. LWN.net. 2017-05-04. > https://lwn.net/Articles/718734/ > You may also be interested in this article too: https://lwn.net/Articles/752613/ Neil points out in the comments that issuing a close() doesn't necessarily initiate any writeback from the kernel. It does on NFS of course, but not on most filesystems. So, a successful return from close() is inconclusive. It just means that the kernel has not hit a writeback error yet, not that the data is truly safe. -- Jeff Layton <jlay...@redhat.com>
