Bug 72213

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:
Always

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.