Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!rice!sun-spots-request From: per@erix.ericsson.se (Per Hedeland) Newsgroups: comp.sys.sun Subject: Re: mounted machine down => df hangs Keywords: Networks Message-ID: <3491@brazos.Rice.edu> Date: 10 Dec 89 21:57:42 GMT Sender: root@rice.edu Organization: Sun-Spots Lines: 31 Approved: Sun-Spots@rice.edu X-Refs: Original: v8n180, Replies: v8n188 v8n193 v8n194 v8n206 X-Sun-Spots-Digest: Volume 8, Issue 213, message 6 of 12 In article <2832@brazos.Rice.edu>, greg@sj.ate.slb.com (Greg Wageman) writes: >This isn't a bug, it's a feature. [lots of explanation deleted...] Well, I'm sure most of us by now have a rather fixed opinion on the truth of that statement, and I don't really intend to comment on it. However, something occurred to me while discussing our latest manifestation of that "feature" (mailtool hanging an entire SunView session because the "mail server" had become inaccessible:-() - sorry if this has already been discussed, if so I must have missed it: As I see it, the purpose of hard mounts is to let programs that don't handle errors on read/write/etc gracefully (which may in some cases be hard to do), work "correctly" all the same. On the other hand, most of the *problems* caused by hard mounts (such as these two examples) seem to be at *initial* file access, i.e. open/stat/etc. (Or, put another way: Most programs don't have files open for long periods of time.) Also, most programs already handle errors at that point - e.g. they are prepared for an expected file to be missing/ inaccessible etc. Now, I know next to nothing about how the NFS protocol works, and thus how feasible this would be, but my conclusion from the above is that it would be *very* useful to have a soft_open_stat_etc_but_hard_read_write_etc option when mounting NFS file systems. Anyone got any comments on this? (Besides "Oh no, not *another* option!":-). Regards --Per Hedeland per@erix.ericsson.se or per%erix.ericsson.se@uunet.uu.net or ...uunet!erix.ericsson.se!per