[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why does close_stdout close stdout and stderr?

From: Jeff Layton
Subject: Re: Why does close_stdout close stdout and stderr?
Date: Mon, 06 May 2019 15:02:12 -0400
User-agent: Evolution 3.32.1 (3.32.1-1.fc30)

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:


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 <address@hidden>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]