All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chuck Lever <chuck.lever@oracle.com>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: nfs@lists.sourceforge.net, Wim Colgate <Wim.Colgate@xensource.com>
Subject: Re: NFS_UNSTABLE vs. FILE and DATA sync.
Date: Mon, 06 Aug 2007 15:35:04 -0400	[thread overview]
Message-ID: <46B777E8.8080401@oracle.com> (raw)
In-Reply-To: <1186427982.6616.67.camel@localhost>

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

Trond Myklebust wrote:
>>> 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.

Take a look at nfs_writeback_done().  You'll see a specific check for a 
"known bug in Tru64 < 5.0" that is exactly the check to see if the 
server is violating this part of the protocol.  Tru64 is not the only 
server where this can happen.

And in fact, the behavior *is* actually "supported" by the client -- I 
believe Linux will attempt to post a COMMIT if the server returns 
NFS_UNSTABLE to *any* write the client has done.

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

No argument there.  Wim, you can precisely determine the request stream 
a server sees with a test client such as pynfs.  However, it appeared 
that you were looking at whole system client-server interaction during 
server instability.

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

  reply	other threads:[~2007-08-06 20:29 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-06 16:02 NFS_UNSTABLE vs. FILE and DATA sync Wim Colgate
2007-08-06 16:37 ` Chuck Lever
2007-08-06 17:10   ` Chuck Lever
2007-08-06 18:58     ` Trond Myklebust
2007-08-06 19:13       ` Chuck Lever
2007-08-06 19:19         ` Trond Myklebust
2007-08-06 19:35           ` Chuck Lever [this message]
2007-08-06 17:33   ` Peter Staubach
2007-08-06 17:40     ` Wim Colgate
2007-08-06 19:16       ` Chuck Lever
2007-08-06 19:33         ` Wim Colgate
2007-08-06 19:42           ` Chuck Lever

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46B777E8.8080401@oracle.com \
    --to=chuck.lever@oracle.com \
    --cc=Wim.Colgate@xensource.com \
    --cc=nfs@lists.sourceforge.net \
    --cc=trond.myklebust@fys.uio.no \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.