On the ease of write() detecting a timely EDQUOT

[Dan Bernstein]

In article <1990Oct21.172956.28324 at athena.mit.edu> jik at athena.mit.edu (Jonathan I. Kamens) writes:
> 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.

Naw. Say your quota is 200 megabytes (okay, so I'm spoiled), and each
process is writing 150. A and B each get starting allocations of a few
megabytes. Each writes some data; when it nears its allocation, it asks
for a bit more.

As they come closer and closer to 100M each, the allocations become
smaller and smaller. The server makes sure never to hand out more than
is actually there. When space becomes really tight, it'll ask each
client to give back any unused allocation, and it'll only give out space
on demand.

In other words, just before EDQUOT, quota testing becomes synchronous
(as it has to be, if you think about it). Having the system slow down
slightly just before failure is a common non-problem. (It's related to
the problem that a disk without much reserved space is going to be
somewhat slower than a disk with the usual 10%.)

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

There does not exist a correct method of handling EDQUOT upon close()
other than having each process invoke the unnecessary extra traffic of
fsync() at various times. I explain this in a previous article.

---Dan