> > 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/