From: Trond Myklebust <trond.myklebust@fys.uio.no>
Subject: Re: NFS_UNSTABLE vs. FILE and DATA sync.
Date: Mon, 06 Aug 2007 15:19:42 -0400
Message-ID: <1186427982.6616.67.camel@localhost>
References: <A9AD3C3BCF83FD4182B7D4D99E37FAD836BEAB@exchrdm.ad.xensource.com>
	<46B74E5C.4060400@oracle.com>  <46B755FE.1010909@oracle.com>
	<1186426710.6616.57.camel@localhost>  <46B772CB.1080906@oracle.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: nfs@lists.sourceforge.net,
	Wim Colgate <Wim.Colgate@xensource.com>
To: chuck.lever@oracle.com
In-Reply-To: <46B772CB.1080906@oracle.com>
Sender: nfs-bounces@lists.sourceforge.net
Errors-To: nfs-bounces@lists.sourceforge.net

On Mon, 2007-08-06 at 15:13 -0400, Chuck Lever wrote:
> Trond Myklebust wrote:
> > On Mon, 2007-08-06 at 13:10 -0400, Chuck Lever wrote:
> >> Even though an NFS client requests an NFS_FILE_SYNC write, the server 
> >> still has the choice of returning something less, even NFS_UNSTABLE.  In 
> >> general that's a rare occurrence, but is something I've seen in practice.
> > 
> > As Peter said, a server that return anything other than FILE_SYNC to a
> > FILE_SYNC write request would be in clear violation of the description
> > of WRITE semantics on page 51 of RFC1813:
> > 
> >       committed
> >          The server should return an indication of the level of
> >          commitment of the data and metadata via committed. If
> >          the server committed all data and metadata to stable
> >          storage, committed should be set to FILE_SYNC. If the
> >          level of commitment was at least as strong as
> >          DATA_SYNC, then committed should be set to DATA_SYNC.
> >          Otherwise, committed must be returned as UNSTABLE. If
> >          stable was FILE_SYNC, then committed must also be
> >          FILE_SYNC: anything else constitutes a protocol
> >          violation. If stable was DATA_SYNC, then committed may
> >          be FILE_SYNC or DATA_SYNC: anything else constitutes a
> >          protocol violation. If stable was UNSTABLE, then
> >          committed may be either FILE_SYNC, DATA_SYNC, or
> >          UNSTABLE.
> > 
> > I see no reason why we should care about supporting such a server.
> 
> I said nothing about whether the server should or should not return such 
> a value.  I just said that it is a possibility, and that I have observed 
> the behavior in the field.
> 
> The client, if it is a good implementation, needs to check for this 
> possibility and throw an error in that case.

We have never supported servers that blatantly violate the protocol, and
I see no reason to be burdening the client with a whole load of checks
for server protocol violations either.

If you want a tool for testing servers, then use something like pynfs.

Trond


-------------------------------------------------------------------------
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs