On the silliness of close() giving EDQUOT

[Barry Shein]

From: gt0178a at prism.gatech.EDU (Jim Burns)
>As far as quotas go, I think it is possible to check that, tho' absolute
>reliablity may incur performance penalties. If quota(1) can tell you what
>you are using, then either the write does the equivalent of quota(1) to
>determine free=quota-used EVERY time, or it does it once at the beginning
>of the program and tries to keep an accurate estimation of what you are
>writing in your program. (Yuech, but it can be done.) (Then again, who
>ever said addons like quotas ever seemlessly interface w/the standard
>system. :-)

What is with all the hand-wringing here? To implement quota you have
to keep one (perhaps two, soft/hard) integers up to date. BFD. On a
single system it has to be kept user-global, in the user struct
basically, one per major/minor device. A pointer to the correct ints
can be thrown in the per-file struct so it all devolves to something
like:

	if((*file[fd].quota - nwrite) < 0)
		bitch;
	else
		*file[fd].quota -= nwrite;

(with appropriate adjustments for blocks and soft/hard) on each write.

For a distributed file system it's harder because of the possibility
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.

Am I missing something hard here?
-- 
        -Barry Shein

Software Tool & Die    | {xylogics,uunet}!world!bzs | bzs at world.std.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD