On the silliness of close() giving EDQUOT

[Jonathan I. Kamens]

In article <BZS.90Oct19231046 at world.std.com>, bzs at world.std.com (Barry Shein) writes:
|> Am I missing something hard here?

  I log into machine A and start a process that's going to write a big file
into AFS.  Then, I log into machine B and do the same thing, but another file.
Either of the files, when finished, will fit into my quota, but not both of
them.

  The process on A and the process on B both query the AFS server to get the
starting quota, and then go ahead and start writing.

  Both of them finish.  The first one to finish will have no problems with the
close().  The second will get EDQUOT.

  As for NFS, as I believe someone else has already pointed out, the NFS
*protocol* is synchronous, but NFS client kernels do not guarantee that the
*client* will get synchronous behavior.

  Assuming that a process/kernel on one machine can accurately keep track of
quotas on a remote filesystem by only making one quota call before doing any
operations on the device is just asking for trouble.  And don't forget that
you're going to have to update the quota status in the kernel after *any* file
operation on that device -- when a file is removed, for example, the local
quota record will have to be updated.  As far as I know, NFS client kernels
don't have to ask how big a file is before they remove it, but if we do what
you suggest, they'd have to do that, because they'd have to be able to
subtract the size of the file from the local quota record.

  All this to avoid EDQUOT on close(), something which I still think is quite
reasonable.

-- 
Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik at Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8085			      Home: 617-782-0710