brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (10/26/90)
In article <1990Oct21.172956.28324@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: > In article <BZS.90Oct19231046@world.std.com>, bzs@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