On the silliness of close() giving EDQUOT

[Robert Thurlow]

In <9681:Oct2004:06:3090 at kramden.acf.nyu.edu> brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:

>In article <thurlow.656303314 at convex.convex.com> thurlow at convex.com (Robert Thurlow) writes:
>> In <24048:Oct1822:23:2090 at kramden.acf.nyu.edu> brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:
>> >["I don't mind close returning -1/EINTR and -1/EBADF."]
>> >No other close() errors make sense.
>> So how do you pick up errors on asynchronous writes?

>That is an excellent question. I suspect that if UNIX had truly
>asynchronous I/O, my objections would disappear, as the whole system
>would work much more cleanly. Somehow I'm not sure the latest mound of
>P1003.4 is the right way to approach asynchronous I/O, but anyway...
>``What asynchronous writes?''

I have them by my definition - "my can process have control before my
data has been committed to permanent storage".  What definition are you
using, and why don't you feel my write(2) calls are asynchronous?

>  [ I object that programs can't afford to keep data around in case of ]
>  [ possible problems; errors must be returned in a timely fashion ]
>> This is ridiculous.  If a program wants to _know_ the data is secured,
>> it can call fsync before it frees the buffers or overwrites the data.

>I sympathize with what you're trying to say, but have you noticed that
>fsync() isn't required to flush data over NFS, any more than write() is
>required to return EDQUOT correctly? If write()'s errors aren't
>accurate, I don't know how you expect fsync() to work.

Our fsync, like Suns, ensures there are no pages in the VM system
marked as "dirty", and it does this by forcing and waiting for I/O
on each such page.  The I/O involves an NFS write, and any I/O errors
are detected.  I consider any system that doesn't do this for me when
I call fsync to be broken.  If you can think of a way that this can
fail to return an error indication to me, please send me a test case.

>> "Allocations"?  I won't lightly put *any* state into my NFS server, never
>> mind state to take care of frivolities like close returning EDQUOT.

>No good remote file system is stateless. I think every complaint I've
>heard about NFS is caused by the ``purity'' of its stateless
>implementation.

No doubt, but I appreciate the advantages of the simplicity this allows.
When it is clear what state we need to introduce to make a more robust
implementation, it'll probably happen.

#include <osi/std/disclaimer>
Rob T
--
Rob Thurlow, thurlow at convex.com or thurlow%convex.com at uxc.cso.uiuc.edu
----------------------------------------------------------------------
"This opinion was the only one available; I got here kind of late."