John R Pierce <pierce@xxxxxxxxxxxx> wrote:
> > Again:
> >
> > - NFSv2 (from 1988) allows 32 Bytes for a NFS file handle
> >
> > - NFSv3 (from 1990) allows 64 Bytes for a NFS file handle
> >
> > - NFSv4 (from 2004) has no hard limit here
> >
> > With the 32 byte file handle, there are still 12 bytes (including a 2 byte
> > length indicator) for the file id in the file handle.
> >
> > If your filesystem could use 44 and more bytes in the case you describe, there
> > is no problem - except when the code is not OK.
> >
> > It is of course nice to still support SunOS-4.0 clients, but in case that the
> > client supports NFSv3 or newer, why not use longer file id's?
> >
>
> we had both solaris 10 aka sunos 5.10 clients and EL5/6 clients. the
> error is "Stale NFS file handle"
So the bug is in the NFS server code.
A NFS file handle is made of a filesystem ID, a file ID for the export
directory and a file ID for the current file.
A file ID is (for a writable filesystem) typically made of the inode number and
a file generation number that is incremented every time a destructive operation
on the file appears.
"Stale NFS file handle" is the error code if the referred file (inode number +
file generation number) no longer exists.
I asume that in your case, the server did send out invalid file IDs that do not
point to a valid file. For this reason, the client gets a "Stale NFS file
handle" when it uses the NFS file handle returned by the NFS server for a
open() operation.
> anyways, this refers to the fsid problem,
> http://xfs.org/index.php/XFS_FAQ#Q:_Why_doesn.27t_NFS-exporting_subdirectories_of_inode64-mounted_filesystem_work.3F
This seems to be an "explanation" from the people who wrote the non-working NFS
code.
> we were unable to make the 'fsid=uuid' option work (or we didn't
> understand it), but using fsid=## for unique integers for each export
> works fine, so thats what we went with.
>
> are these fsid's the same as your 32 vs 64 bit file handles ? doesn't
> sound like it to me, unless I'm misunderstanding what you're referring
> to as a file handle.
If you introduce new words, you would need to explain them. I can only explain
how NFS works and that it is possible to use NFS to export filesystems with
more than 32 bit inode numbers.
Just a note: even with NFSv2, you could have an 8 Byte inode number + 2 Byte
file generation number or 7 Byte inode number + 3 byte file generation number
or 6 Byte inode number + 4 Byte file generation number.
It is most unlikely that a filesystem designed for NFSv2 export will use the
full 8 byte address space that 64 bit inode number could allow.
Jörg
--
EMail:joerg@xxxxxxxxxxxxxxxxxxxxxxxxxxx (home) Jörg Schilling D-13353 Berlin
js@xxxxxxxxxxxxxxx (uni)
joerg.schilling@xxxxxxxxxxxxxxxxxxx (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
