>>From: David S. Miller <davem@redhat.com>
>> From: Alan Cox <alan@lxorguk.ukuu.org.uk>
>> Date: 17 Jul 2002 02:35:41 +0100
>>
>> Our NFS can return errors from close().
>>
>>Better tell Linus.
>
> Oh, Linus knows. In fact, Linus wrote some of the code in question.
>
> But the thing is, Linus doesn't want to have people have the same issues
> with local filesystems. I _know_ there are broken applications that do
> not test the error return from close(), and I think it is a politeness
> issue to return error codes that you can know about as soon as humanly
> possible.
> For NFS, you simply cannot do any reasonable performance without doing
> deferred error reporting. The same isn't true of other filesystems.
> Even in the presense of delayed block allocation, a local filesystem can
> _reserve_ the blocks early, and has no excuse for giving errors late
> (except, of course, for actual IO errors).
I really hate to disagree with the chief penguin here, but
it's extremely dumb to return errors from close(). The last
time we trashed this issue on this list was when a newbie used
an error return from release() to communicate with his driver.
The problem with errors from close() is that NOTHING SMART can be
done by the application when it receives it. And application can:
a) print a message "Your data are lost, have a nice day\n".
b) loop retrying close() until it works.
c) do (a) then (b).
The thing about (b) is that the kernel can do it much better.
Another thing proponents of errors from close() better ask themselves
is if the file descriptor stays open or closed if close() abends.
If it remains open, your exit() is bust. If it closes, you
cannot retry the error (b).
-- Pete
-
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:25 EST