Path: utzoo!attcan!uunet!world!bzs From: bzs@world.std.com (Barry Shein) Newsgroups: comp.unix.internals Subject: Re: On the silliness of close() giving EDQUOT Message-ID: Date: 20 Oct 90 03:10:46 GMT References: <1990Oct19.055913.7103@athena.mit.edu> <15480@hydra.gatech.EDU> Sender: bzs@world.std.com (Barry Shein) Organization: The World Lines: 37 In-Reply-To: gt0178a@prism.gatech.EDU's message of 19 Oct 90 09:25:14 GMT From: gt0178a@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@world.std.com Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD