All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Staubach <staubach@redhat.com>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Neil Brown <neilb@suse.de>,
	Linux NFS Mailing List <nfs@lists.sourceforge.net>
Subject: Re: Can we flush directory data when the ctime changes?
Date: Tue, 08 Aug 2006 10:27:23 -0400	[thread overview]
Message-ID: <44D89F4B.8080702@redhat.com> (raw)
In-Reply-To: <1155045918.5673.26.camel@localhost>

Trond Myklebust wrote:
> On Tue, 2006-08-08 at 17:26 +1000, Neil Brown wrote:
>   
>> Hi,
>>  We have a scenario where readdir in the linux client gets confused by 
>> responses from a Netapp fileserver.
>>
>> What happens is that a readdir collects and caches the directory.
>> Then a subsequent readdir finds the first page is still in the cache
>> but the second page is missing.
>> The nfs client uses a cookie from the first page to request subsequent
>> entries and received a list of entries starting from the beginning of
>> the directory rather than from the point that it was up to.   It seems
>> that the cookies have changed.
>>
>> The GETATTR call that the client makes to validate the cache reports
>> that the mtime hasn't change, *but the ctime has*.
>>     
>
> Growl! If the directory contents change, then the mtime should too. Page
> 22 of RFC1813:
>
>         Mtime is the time when the file data was last modified.  Ctime
>         is the time when the attributes of the file were last changed.
>
> Directory cookies are not file or directory attributes!
>
> In addition, NFSv3 has the cookie verifier mechanism for the server to
> specifically inform the client that the cookies are invalid.
>
> IOW: this really needs to be fixed on the _server_. I'm not happy taking
> new patches that may cause the client GETATTR calls to skyrocket again.

This really does seem like a bug in the NetApp server.  With a change
like this, a simple chmod(2) could cause the client to invalidate its
caches...

       ps

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

  reply	other threads:[~2006-08-08 14:27 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-08  7:26 Can we flush directory data when the ctime changes? Neil Brown
2006-08-08 13:28 ` Chuck Lever
2006-08-08 14:05 ` Trond Myklebust
2006-08-08 14:27   ` Peter Staubach [this message]
2006-08-08 14:35     ` Trond Myklebust
2006-08-15  3:49   ` Neil Brown
2006-08-15 15:26     ` Peter Staubach

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=44D89F4B.8080702@redhat.com \
    --to=staubach@redhat.com \
    --cc=neilb@suse.de \
    --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.