Path: utzoo!attcan!uunet!convex!convex.convex.com!thurlow From: thurlow@convex.com (Robert Thurlow) Newsgroups: comp.unix.internals Subject: Re: On the silliness of close() giving EDQUOT Message-ID: Date: 28 Oct 90 17:50:28 GMT References: <15480@hydra.gatech.EDU> <1990Oct26.050448.26816@fts1.uucp> Sender: news@convex.com Lines: 37 In <1990Oct26.050448.26816@fts1.uucp> michael@fts1.uucp (Michael Richardson) writes: > 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. This might be workable; the only problem is the NFS protocol change required to carry the quota information, because we're still waiting for a couple of more serious things to be fixed. > 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. While I like to handle errors, I _demand_ to know about them so that I can warn my users. Even here, a workaround might be to have the process retry the close so the kernel will retry the NFS writes, after telling the user he is over quota so that he can try to delete some files on the server. If your process exited, _close() could just go ahead and burn the blocks out of the cache. > Someone's .sig said something like "Only check for errors >you know how to deal with." --- I like the spirit of this. Hey, warning a user is still better than ignoring an error condition your program can't handle. #include Rob T -- Rob Thurlow, thurlow@convex.com or thurlow%convex.com@uxc.cso.uiuc.edu ---------------------------------------------------------------------- "This opinion was the only one available; I got here kind of late."