Path: utzoo!attcan!uunet!cs.utexas.edu!sun-barr!newstop!texsun!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: 21 Oct 90 00:21:23 GMT References: <1990Oct18.200939.17427@athena.mit.edu> <24048:Oct1822:23:2090@kramden.acf.nyu.edu> <9681:Oct2004:06:3090@kramden.acf.nyu.edu> Sender: usenet@convex.com Lines: 52 In <9681:Oct2004:06:3090@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >In article thurlow@convex.com (Robert Thurlow) writes: >> In <24048:Oct1822:23:2090@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >> >["I don't mind close returning -1/EINTR and -1/EBADF."] >> >No other close() errors make sense. >> So how do you pick up errors on asynchronous writes? >That is an excellent question. I suspect that if UNIX had truly >asynchronous I/O, my objections would disappear, as the whole system >would work much more cleanly. Somehow I'm not sure the latest mound of >P1003.4 is the right way to approach asynchronous I/O, but anyway... >``What asynchronous writes?'' I have them by my definition - "my can process have control before my data has been committed to permanent storage". What definition are you using, and why don't you feel my write(2) calls are asynchronous? > [ I object that programs can't afford to keep data around in case of ] > [ possible problems; errors must be returned in a timely fashion ] >> This is ridiculous. If a program wants to _know_ the data is secured, >> it can call fsync before it frees the buffers or overwrites the data. >I sympathize with what you're trying to say, but have you noticed that >fsync() isn't required to flush data over NFS, any more than write() is >required to return EDQUOT correctly? If write()'s errors aren't >accurate, I don't know how you expect fsync() to work. Our fsync, like Suns, ensures there are no pages in the VM system marked as "dirty", and it does this by forcing and waiting for I/O on each such page. The I/O involves an NFS write, and any I/O errors are detected. I consider any system that doesn't do this for me when I call fsync to be broken. If you can think of a way that this can fail to return an error indication to me, please send me a test case. >> "Allocations"? I won't lightly put *any* state into my NFS server, never >> mind state to take care of frivolities like close returning EDQUOT. >No good remote file system is stateless. I think every complaint I've >heard about NFS is caused by the ``purity'' of its stateless >implementation. No doubt, but I appreciate the advantages of the simplicity this allows. When it is clear what state we need to introduce to make a more robust implementation, it'll probably happen. #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."