Control NFS exported filesystems

[John F Haugh II]

In article <1991Jun20.090136.14351 at ioe.lon.ac.uk>, teexand at ioe.lon.ac.uk (Andrew Dawson) writes:
> In <1991Jun19.162331.25505 at bellcore.bellcore.com> jona at iscp.Bellcore.COM (Jon Alperin) writes:
> 
> >	Hey...maybe this explains the reason that when I save a file
> >under VI which is kept on another NFS partition, VI tells me that it
> >was able to save the file, but because the real physical disk was full I
> >end up with a 0 length file (and lose all my work).....
> 
> This sounds like something we have been discussing with IBM recently. I think
> essentially the client is cacheing requests, so although write() returns
> sucessfully, the data hasn't been written to disk. Your application may pick
> up an error if fsync is called, and the close should also fail (not that many
> applications check this). However, I'm not sure even this much worked until
> we'd applied an APAR fix.

There have been problems with "vi" and other applications which do not check
the return status of "close" when using NFS on certain file systems.  For
example, I worked on an APAR where "vi" of a file on an NFS-mounted MVS file
system failed if the file was extended.  The solution was, as I recall, to
have fsync() called and to check its return status.

I'd suggest that anyone who finds a problem where a program thinks it has
exited successfully, but the data wasn't written, open an APAR.  The cause
will probably be very similiar.
-- 
John F. Haugh II        | Distribution to  | UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 255-8251 | GEnie PROHIBITED :-) |  Domain: jfh at rpp386.cactus.org
"UNIX signals are not interrupts.  Worse, SIGCHLD/SIGCLD is not even a UNIX
 signal, it's an abomination."  -- Doug Gwyn