Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!turnkey!jackv
From: jackv@turnkey.tcc.com (Jack F. Vogel)
Newsgroups: comp.unix.aix
Subject: Re: Control NFS exported filesystems
Message-ID: <1991Jun19.172354.9964@turnkey.tcc.com>
Date: 19 Jun 91 17:23:54 GMT
References: <91169.000329CALT@SLACVM.SLAC.STANFORD.EDU> <8567@awdprime.UUCP> <1991Jun19.154830.17276@uai.com> <1991Jun19.162331.25505@bellcore.bellcore.com>
Reply-To: jackv@turnkey.TCC.COM (Jack F. Vogel)
Organization: Turnkey Computer Consultants, Westchester, CA
Lines: 30

In article <1991Jun19.162331.25505@bellcore.bellcore.com> jona@iscp.Bellcore.COM (Jon Alperin) writes:
>In article <1991Jun19.154830.17276@uai.com>, mrl@uai.com (Mark R. Ludwig) writes:
[ stuff about using the 'hard' mount for data integrity deleted...]
>
>	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).....
 
No, I don't believe that mounting the filesystem 'hard' will prevent this
from happening. The reason this can happen is that the NFS client is doing
a bawrite() (asynchronous) so it doesn't get an immediate error, rather
just the inode is marked in error. If you wrote enough data that multiple
calls to bawrite() were necessary then the error would be noticed and vi
would tell you.

In the NFS in BSD 4.3 reno, there was a mount option 'synchronous' that
solves this by forcing the client to use bwrite(), thus you will be
guaranteed to see the error, of course you are going to suffer somewhat
of a performance hit by using it. I don't know if the current SunOS has
such an option or not. Also I don't know what level of NFS the 6000 is
based on, so it could have such an option for all I know, check the
man page for mount.

Disclaimer: I'm a kernel hacker not a company spokesweenie :-}.

-- 
Jack F. Vogel			jackv@locus.com
AIX370 Technical Support	       - or -
Locus Computing Corp.		jackv@turnkey.TCC.COM