[NFS] [PATCH] NFS: have string-based mount options default to "intr" mounts

[Jeff Layton]

On Wed, 25 Jul 2007 19:48:06 -0400
Jeff Layton <jlayton at redhat.com> wrote:

> On Wed, 25 Jul 2007 17:07:15 -0400
> Peter Staubach <staubach at redhat.com> wrote:
> 
> > Jeff Layton wrote:
> > > On Wed, 25 Jul 2007 16:16:57 -0400
> > > Trond Myklebust <trond.myklebust at fys.uio.no> wrote:
> > >
> > >   
> > >> On Wed, 2007-07-25 at 15:41 -0400, Jeff Layton wrote:
> > >>     
> > >>> On Wed, 25 Jul 2007 15:36:18 -0400
> > >>> Chuck Lever <chuck.lever at oracle.com> wrote:
> > >>>
> > >>>       
> > >>>> I thought "nointr" was the default because it is safest.
> > >>>>
> > >>>>         
> > >>> I could see maybe with soft mounts, but in conjunction with a hard
> > >>> mount (which is the default) is there danger of corruption?
> > >>>       
> > >> You may cause the sync to disk on close() to be aborted. The writes will
> > >> eventually get flushed to disk by the flushd() daemon, but failing to
> > >> sync writes to disk prior to closing the file is a violation of
> > >> close-to-open caching semantics and may cause corruption issues.
> > >>
> > >> Trond
> > >>
> > >>     
> > >
> > > The close would return EINTR in this case though, wouldn't it? The app
> > > should then be aware that it didn't actually happen and should
> > > reattempt it. Presuming that the app handles this correctly, is it
> > > really a data corruption issue?
> > 
> > You can't retry the operation.  Even if close() returns an error,
> > the file descriptor is really closed.
> > 
> 
> Interesting. The close(2) manpage is unclear on this on this point.
> 
> > But, the application can take some other form of error recovery.
> > 
> > ----
> > 
> > I think that I object the data corruption characterization.  The
> > data doesn't become corrupted.  It, eventually, is written out to
> > stable storage.  However, an application which concerned with
> > consistency needs to be able to do something valid when a close
> > operation returns an error, whether it is EINTR or something else.
> > 
> 
> That's my thinking too, though if you close and get an error, it's
> not clear to me what that should be. There doesn't seem to be a way to
> block waiting for the data to be flushed out. If the fd is closed, I
> suppose you would have released any locks you have. Other machines
> would be able to get in there before your data gets flushed to the
> server.
> 
> Now that I think about it, I guess we have similar issues with nointr
> if the server reboots at just the wrong time during a close call too.
> 

Actually, this is probably not correct. I was thinking that if the
server rebooted during a commit call issued on a close then the app
would need to reissue the writes. I don't think this is the case
though...

> In any case, I guess the question here is "what should the default be"?
> Currently, it's nointr for nfs2/3 and intr for nfs4. If you use
> string-based options, it's nointr everywhere. I think we ought to try to
> make it consistent unless there's good reason not to. We should also
> make sure the nfs manpage is correct.
> 
> --
> Jeff Layton <jlayton at redhat.com>
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> NFS maillist  -  NFS at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs
> 


-- 
Jeff Layton <jlayton at poochiereds.net>