Messages in this thread | | | Date | Wed, 10 Feb 1999 10:35:04 -0800 | From | "H.J. Lu" <> | Subject | Re: A Linux NFS server problem with Solaris/SunOS clients. |
| |
Mike Eisler wrote:
> > Hi, > > > > I am running Linux 2.2.1 with kernel nfs. I have a Solaris 2.7/x86 > > client and a SunOS 4.1.2 client. On SunOS 4.1.2 client, when I > > do > > > > # touch test.c > > # ls -l test.c > > -rw-r--r-- 1 hjl hjl 126 May 18 1902 test.c > > > > BTW, how does it set to 1902? Maybe it is a Y2K bug in SunOS. > > Maybe. A snoop trace would be interesting. If it is SunOS 4.1.2, there > won't be any y2k fixes (4.1.3_u1 Version B is as low as we go). > > > > > Then on Solaris client, I got > > > > # ls -l test.c > > ls: test.c: Value too large for defined data type > > Yes, in Solaris7 we decided it was time to comply with the NFS protocol > spec, which says that file times are 32 bit unsigned values in > seconds from 1970-01-01-00:00:00 > > > 220321 is the inode number for ".". For some reason, Solaris got > > confused after a while when you delete/create the same file over > > and over. A remount fixed Solaris. > > If you delete file X with inode # 220321, and then immediately create a new > directory, on many UNIX file systems, the inode # of the directory will also > be 2220321. If the NFs fiel handles are the same, really bad things happen. So > in most NFS servers, the file handle includes a generation count that is > stored in the inode. > > What steps does the Linux NFS server take to prevent file handle re-use?
Nothing. Now I found the problem. In my case, there are symlinks/regular files got deleted/created very frequently in the same directory. That exaplains why Solaris calls READLINKon a newly created regular file since it has the same file handle as the previously removed symlink.
Linus, can we add a generation count or something like that in Linux's inode?
Thanks.
H.J.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |