On the silliness of close() giving EDQUOT

[Michael Richardson]

In article <thurlow.656468286 at convex.convex.com> thurlow at convex.com (Robert Thurlow) writes:
>In <BZS.90Oct19231046 at world.std.com> bzs at world.std.com (Barry Shein) writes:
>>of multiple writing processes. But writes in NFS are synchronous, so
>>that's not hard, the server knows and will return the error and the
>>write() doesn't return until it's committed. If you shut that off for
>>performance gains you're on your own.

>write(2) is not synchronous to the process; the NFS write operation is,
>but they may be done later by block I/O daemon processes on your behalf
>at a later time.  We allow synchronous writes, but that isn't what a
>naive process gets.

  Seems to me that the above two statements solve the problem:
  If NFS write()s are synchronous, then the server can certainly
take care of EDQUOT during the request. The write will fail. A simple
modification to the NFS write operation would return the quota left
on that device on each request (Disclaimer: it has been over a year since
I did anything serious with SUNs or equivalent NFS' machined, two years 
since I read the NFS and XDR stuff)
  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. 
  (biod's are kernel processes, so it is the kernel that is 
worrying about the quota. Same difference.)

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

-- 
   :!mcr!:            |    The postmaster never          |  So much mail,
   Michael Richardson |            resolves twice.       |  so few cycles.
 Play: mcr at julie.UUCP Work: michael at fts1.UUCP Fido: 1:163/109.10 1:163/138
    Amiga----^     - Pay attention only to _MY_ opinions. -   ^--Amiga--^