Bug 803648 - The NFS mounted share shows different inodes on clients.
Summary: The NFS mounted share shows different inodes on clients.
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: nfs-utils
Version: 4.8
Hardware: i386
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: nfs-maint
QA Contact: Red Hat Kernel QE team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-03-15 10:56 UTC by Rituraj
Modified: 2012-06-20 13:32 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-06-20 13:32:42 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Rituraj 2012-03-15 10:56:43 UTC
Description of problem:

This inode number is shown as different on a directory mounted from NFS - on different clients. When we move the directory name to different dir - the inode name shows SAME on both clients but when we move name to original name, again the inode difference is there. 
As a result of this the files created in the directory from one client does not reflect on another. This bug is related to bug numbers 327591 & 228801. 
I am opening this here again as the ERRATA for the earlier bugs was for 2.6.9-67 kernel, whereas we are runnning 2.6.9-87 kernel. The earlier bugs are closed.

Version-Release number of selected component (if applicable):
[root@ora-stage-ebs-app-4 ~]# rpm -qa | grep -i nfs
nfs-utils-lib-1.0.6-10.el4
nfs-utils-1.0.6-93.EL4
[root@ora-stage-ebs-app-4 ~]# uname -a
Linux ora-stage-ebs-app-4.vmware.com 2.6.9-89.0.11.0.1.ELsmp #1 SMP Tue Sep 15 13:54:39 EDT 2009 i686 i686 i386 GNU/Linux
[root@ora-stage-ebs-app-4 ~]# cat /etc/issue
Enterprise Linux Enterprise Linux AS release 4 (October Update 8)
Kernel \r on an \m




How reproducible:

Has been happening on many clients on one directory. All other subdirectories are fine.

Steps to Reproduce:

oving directory name to a different name makes the inode appear as same on both NFS clients. When the directory name is back to original, the inode number is DIFFERENT on both clients.

As this NFS is from a NAS box, cant check from "server" side.

Comment 1 Fabio Olive Leite 2012-03-15 20:07:35 UTC
Please paste here the outputs of the commands you use to reproduce and verify this problem, so that we can have a clear understanding of what you mean by "inode difference".

Can you also provide a binary packet capture (tcpdump) containing the packets exchanged with the server during these operations? It will be very important to check the server responses in detail to understand this issue.

Thanks!

Comment 2 Rituraj 2012-03-21 13:32:56 UTC
The Inode number for "admin" subdirectory was shown differently on different clients. Finally we had to change the name of the folder to admin-1 - and create a symlink "admin" - which pointed to admin-1.
Though the symlink has different inode number on NFS mounted clients, it in turn points to admin-1 which has SAME inode number across all.

ls -li
total 1825992
2867351 lrwxrwxrwx   1 root    root          7 Mar 15 08:13 admin -> admin-1
4787546 drwxr-xr-x   8 applmgr dba        1024 Mar 20 13:23 admin-1
4045782 drwxr-xr-x   9 applmgr dba        1024 Mar 20 10:22 clone
2823871 drwxr-xr-x  10 applmgr dba        1024 Mar 13 02:15 conf
4040492 drwxr-xr-x  36 applmgr dba      926720 Mar 15 12:47 html



Please let me know what tcpdump o/p you need. As mentioned we cant do tcpdump as the server is NAS share.

Comment 3 Jiri Pallich 2012-06-20 13:32:42 UTC
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. 
Please See https://access.redhat.com/support/policy/updates/errata/

If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.


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