Path: utzoo!dciem!nrcaer!cunews!fts1!michael From: michael@fts1.uucp (Michael Richardson) Newsgroups: comp.unix.internals Subject: Re: On the silliness of close() giving EDQUOT Summary: If anyone is taking a vote. I agree with the Subject: Message-ID: <1990Oct26.050448.26816@fts1.uucp> Date: 26 Oct 90 05:04:48 GMT References: <15480@hydra.gatech.EDU> Organization: Fountain Technical Services, Ottawa, ON Lines: 40 In article thurlow@convex.com (Robert Thurlow) writes: >In bzs@world.std.com (Barry Shein) writes: >>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. >write(2) is not synchronous to the process; the NFS write operation is, >but they may be done later by block I/O daemon processes on your behalf >at a later time. We allow synchronous writes, but that isn't what a >naive process gets. Seems to me that the above two statements solve the problem: If NFS write()s are synchronous, then the server can certainly take care of EDQUOT during the request. The write will fail. A simple modification to the NFS write operation would return the quota left on that device on each request (Disclaimer: it has been over a year since I did anything serious with SUNs or equivalent NFS' machined, two years since I read the NFS and XDR stuff) Now, the biod processes are the ones that get you the asynchronous write(2) operation on remote file systems, so it seems that THEY should be the one that worries about whether there is enough disk quota left. At some point where the number of blocks left is the maximum number that could be queued, the write() operation becomes synchronous. (biod's are kernel processes, so it is the kernel that is worrying about the quota. Same difference.) Checking for EDQUOT on close() might be a good idea, (like checking return codes for ANY system of library call) but what you'd do after getting it (and taking the data from a pipe, or a tty --- a user) is beyond me. Someone's .sig said something like "Only check for errors you know how to deal with." --- I like the spirit of this. -- :!mcr!: | The postmaster never | So much mail, Michael Richardson | resolves twice. | so few cycles. Play: mcr@julie.UUCP Work: michael@fts1.UUCP Fido: 1:163/109.10 1:163/138 Amiga----^ - Pay attention only to _MY_ opinions. - ^--Amiga--^