Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!romp!auschs!awdprime!ekhomeni.austin.ibm.com!marc
From: marc@ekhomeni.austin.ibm.com (Marc Wiz)
Newsgroups: comp.unix.aix
Subject: Re: Control NFS exported filesystems
Message-ID: <8623@awdprime.UUCP>
Date: 20 Jun 91 00:57:10 GMT
References: <1991Jun19.172354.9964@turnkey.tcc.com> <91169.000329CALT@SLACVM.SLAC.STANFORD.EDU> <8567@awdprime.UUCP> <1991Jun19.154830.17276@uai.com> <1991Jun19.162331.25505@bellcore.bellcore.com>
Sender: news@awdprime.UUCP
Reply-To: marc@aixwiz.austin.ibm.com
Organization: Do you really want to know?
Lines: 71

In article <1991Jun19.172354.9964@turnkey.tcc.com>,
jackv@turnkey.tcc.com (Jack F. Vogel) writes:
> From: jackv@turnkey.tcc.com (Jack F. Vogel)
> >	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.

Mounting the file system hard will not prevent the problem.  An
application will
not "see" the error until a fsync or close is done on the file.  Probably what
is happening with vi is that it is not checking the return from close.  I can't
ever remember seeing someone check the return from a close with all the
code that
I have looked at.  (I'm sure there are folks out there who have looked
at a lot more
code that I have :-)

NFS for the 6000 does not have a sync option for mount.  There is a way to
force synchronous operations on a file.  First of all opening the file
O_SYNC does NOT
do it.  (I don't know whether this is a problem or not)  The way to do
it is to open the
file and then obtain a lock on a piece of the file.  When NFS sees that
a lock has been
obtained it turns off caching for that file.

One thing to point out is that you would take one heck of a performance
hit if you were
running synchronously.  One could do a fsync after every write but that
means taking a 
performance hit not to mention you have to change your application.  I'm
sure that there
are other ways to handle this without impacting performance too much. 
One way to do
it (IMHO) is to have your application hold on to it's buffers between
fsync calls.
If you get an error from fsync, correct the problem and then reissue the
fsync for that
batch of writes.  This means that the application will need someway of
knowing when to
resume (i.e. the problem aka file system full has been corrected)


As an aside does anyone out there check the return from close in their
programs?

Marc Wiz 				MaBell (512)823-4780

NFS/NIS Change team
Yes that really is my last name.
The views expressed are my own.

marc@aixwiz.austin.ibm.com 
or
uunet!cs.utexas.edu!ibmchs!auschs!ekhomeni.austin.ibm.com!marc