Re: NFS_UNSTABLE vs. FILE and DATA sync.

[Chuck Lever <chuck.lever@oracle.com>]

[-- Attachment #1: Type: text/plain, Size: 1724 bytes --]

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.

[-- Attachment #2: chuck.lever.vcf --]
[-- Type: text/x-vcard, Size: 290 bytes --]

begin:vcard
fn:Chuck Lever
n:Lever;Chuck
org:Oracle Corporation;Corporate Architecture: Linux Projects Group
adr:;;1015 Granger Avenue;Ann Arbor;MI;48104;USA
title:Principal Member of Staff
tel;work:+1 248 614 5091
x-mozilla-html:FALSE
url:http://oss.oracle.com/~cel
version:2.1
end:vcard


[-- Attachment #3: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
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/

[-- Attachment #4: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs