On Wed, Jul 17, 2002 at 02:45:40AM +0100, Alan Cox wrote:
> On Wed, 2002-07-17 at 01:10, Zack Weinberg wrote:
> > My first point is that a portable application cannot rely on close to
> > detect any error. Only fsync guarantees to detect any errors at all
> > (except ENOSPC/EDQUOT, which should come back on write; yes, I know
> > about the buggy NFS implementations that report them only on close).
>
> They are not buggy merely inconvenient. The reality of the NFS protocol
> makes it the only viable way to do it
You are referring to the way NFSv2 lacks any way to request space
allocation on the server without also flushing data to disk? It was
my understanding that NFSv2 clients that did not accept the
performance hit and do all writes synchronously were considered
broken. (since, for instance, POSIX write-visibility guarantees are
violated if writes are delayed on the client.)
In v3 or v4, the WRITE/COMMIT separation lets the implementor generate
prompt ENOSPC and EDQUOT errors without performance penalty.
Another thing to keep in mind is that an application is often in a
much better position to recover from an error, particularly a
disk-full error, if it's reported on write rather than on close.
That's just a quality-of-implementation question, though.
> > > If it bothers you close it again 8)
> >
> > And watch it come back with an error again, repeat ad infinitum?
>
> The use of intelligence doesn't help. Come on I know you aren't a cobol
> programmer. Check for -EBADF ...
I wasn't talking about EBADF. How does the application know the
kernel will ever succeed in closing the file?
> Disagree. It says
>
> It is quite possible that errors on a previous write(2) operation
> are first reported at the final close
>
> Not checking the return value when closing the file may lead to silent
> loss of data.
>
> A successful close does not guarantee that the data has
> been successfully saved to disk, as the kernel defers
> writes. It is not common for a filesystem to flush the
> buffers when the stream is closed. If you need to be sure
> that the data is physically stored use fsync(2). (It will
> depend on the disk hardware at this point.)
>
> None of which guarantee what you say, and which agree about the use of
> fsync being appropriate now and then
That is not the text quoted upthread. Looks like the manpage did get
fixed, although I think the current wording is still suboptimal.
zw
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Jul 23 2002 - 22:00:24 EST