Bug 72213 - NFS v3 client caches directories causing stale file handles
Summary: NFS v3 client caches directories causing stale file handles
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
(Show other bugs)
Version: 7.3
Hardware: All Linux
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2002-08-21 23:50 UTC by Jefferson Ogata
Modified: 2008-08-01 16:22 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-30 15:39:51 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Jefferson Ogata 2002-08-21 23:50:48 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020513

Description of problem:
When an NFS filesystem is mounted with version 3, the kernel appears to cache
directories. If a directory's modification time is unchanged, it will not
re-read the directory. This causes problems when a process such as rsync
replaces files in the directory but restores the directory's modification time.

For example, suppose directory source:/A is being mirrored to directory dest:/B
with rsync. A user on source modifies the existing file source:/A/x. The
directory /A is not modified; only the file is modified. When rsync mirrors
source:/A to dest:/B, it will unlink the old version of dest:/B/x and create a
new one, using a new inode. This changes the NFS filehandle for dest:/B/x. Now,
although rsync's operations will implicitly change the modification time of
dest:/B, rsync will then restore the modification time of /B back to its
original value. Now when a Red Hat Linux 7.3 NFS v3 client which has mounted
dest:/B attempts to access dest:/B/x, it will be using a stale file handle.
Because the directory modification time is unchanged, the kernel does not reread
the directory, so it is unaware the dest:/B/x's file handle has changed.

This problem does not occur when the client uses NFS v2.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. On an RH 7.3 system "server" set up as an NFS server, I create directory
/export/x. Within it I create a file "a". I record the modification time of
/export/x using "touch -r /export/x /tmp/x-time".

2. On an RH 7.3 system "client", I mount server:/export/x onto /mnt/x using NFS
v3, e.g. "mount -o ro,vers=3,intr server:/export/x /mnt/x". I then "ls -lia
/mnt/x/". I see ., .., and a.

3. On "server", I now do the following: "cd /export/x; cp -p a aa; mv aa a;
touch -r /tmp/x-time ." That is, I recreate "a" using a new inode, and set the
modification time of /export/x back to its original value.

4. On "client", I repeat the "ls -lia /mnt/x/". I get a "a: Stale NFS file
handle" error. This is because the client is not re-reading the directory and is
therefore not observing that the file handle for "a" has changed.

Actual Results:  a: Stale NFS file handle.

Expected Results:  The client should have listed ., .., and a, and a's inode
number should have reflected the change.

Additional info:

If I perform the above operation using "vers=2" in the mount options on
"client", the problem does not occur.

Comment 1 Jefferson Ogata 2002-08-22 17:19:53 UTC
Disabling attribute caching with the noac option appears to mitigate this bug,
although I still observed a Stale file handle error logged at a time when I am
99% sure that noac was in effect.

I imagine that someone thought it would be clever to use a directory cache to
optimize against re-reading large directories that are unchanged, by checking
mod time on the directory first. I think perhaps this would be an arguable
position, if the check verified also that the inode change time is intact. As it
is, the typical deployment of rsync with the --times option will exercise this
bug. If a check was added for inode change time, then this problem would go away.

Even so, there will be cases where the bug still causes problems, but they will
be far fewer.

Comment 2 Jefferson Ogata 2002-11-16 03:24:31 UTC

Comment 3 Bugzilla owner 2004-09-30 15:39:51 UTC
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/

Note You need to log in before you can comment on or make changes to this bug.