All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Dickson <SteveD@redhat.com>
To: nfs@lists.sourceforge.net
Subject: Disappearing NFS directories
Date: Wed, 27 Aug 2003 17:28:18 -0400	[thread overview]
Message-ID: <3F4D2272.1050003@RedHat.com> (raw)

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

On a couple of 64 bit (mostly ia64 and ppc64) NFS
client machines, the contents of remotely mountd
directories would either disappear or not be
seen at all. Other clients mounting the same
filesystem to the same server are able to see
everything... After doing some experiments there
appears to be some issues with readdirplus caching.
Here is what I found:

If the blind client explicitly does an /bin/ls
on a file in the empty directory, the file is found.

If the blind client create a file in the
'empty' directory, all of the other file
reappear... which make sense because the first
thing nfs_create does is a nfs_zap_caches(dir);

But when the "blind" client /bin/touch the directory
(i.e. updates the atime) the files don't comeback
but the mtime on the directory is updated...

So basically it looks like there are two problems:
1) some type of race condition puts the client in this condition
2) the readdirplus cache is not being flush at the appropriate time....

I've attached a patch that I think will take care
of the second issue. Unfortunately these are production
machine so I have not been able to test this patch (yet).

I noticed in __nfs_refresh_inode() that the invalid flag
was being turned off when the WCC attrs matched up with
the current cache values. Now I'm not sure if this makes
sense wrt to the readdir cache because if
(NFS_CACHE_ISIZE(inode) != new_size) is true AND/OR
(NFS_CACHE_MTIME(inode) != new_mtime) is true
we really need to flush the cache... right?

So the patch does *not* turn off the invalid flag
the WCC attrs match and its a directory inode...


SteveD.





[-- Attachment #2: linux-2.4.21-nfs-readdircache.patch --]
[-- Type: text/plain, Size: 473 bytes --]

--- linux-2.4.21/fs/nfs/inode.c.diff	2003-08-27 12:44:13.000000000 -0400
+++ linux-2.4.21/fs/nfs/inode.c	2003-08-27 16:02:52.000000000 -0400
@@ -1189,7 +1189,8 @@ __nfs_refresh_inode(struct inode *inode,
          */
         if ((fattr->valid & NFS_ATTR_WCC)
 	    && NFS_CACHE_ISIZE(inode) == fattr->pre_size
-	    && NFS_CACHE_MTIME(inode) == fattr->pre_mtime) {
+	    && NFS_CACHE_MTIME(inode) == fattr->pre_mtime
+		&& !S_ISDIR(inode->i_mode)) {
 		invalid = 0;
 	}
 

                 reply	other threads:[~2003-08-27 21:27 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=3F4D2272.1050003@RedHat.com \
    --to=steved@redhat.com \
    --cc=nfs@lists.sourceforge.net \
    /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.