[CentOS] compare zfs xfs and jfs o

[Joerg Schilling]

John R Pierce <pierce at hogranch.com> 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 at schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily