On the silliness of close() giving EDQUOT

[Robert Thurlow]

In <1990Oct26.050448.26816 at fts1.uucp> michael at fts1.uucp (Michael Richardson) writes:

>  Now, the biod processes are the ones that get you the asynchronous
>write(2) operation on remote file systems, so it seems that THEY
>should be the one that worries about whether there is enough disk
>quota left. At some point where the number of blocks left is
>the maximum number that could be queued, the write() operation
>becomes synchronous. 

This might be workable; the only problem is the NFS protocol change
required to carry the quota information, because we're still waiting
for a couple of more serious things to be fixed.

>  Checking for EDQUOT on close() might be a good idea, 
>(like checking return codes for ANY system of library call)
>but what you'd do after getting it (and taking the data from
>a pipe, or a tty --- a user) is beyond me. 

While I like to handle errors, I _demand_ to know about them so that
I can warn my users.  Even here, a workaround might be to have the
process retry the close so the kernel will retry the NFS writes, after
telling the user he is over quota so that he can try to delete some
files on the server.  If your process exited, _close() could just go
ahead and burn the blocks out of the cache.

>  Someone's .sig said something like "Only check for errors
>you know how to deal with." --- I like the spirit of this.

Hey, warning a user is still better than ignoring an error condition
your program can't handle.

#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."