[CentOS] compare zfs xfs and jfs o

[John R Pierce]

On 08/05/12 3:18 PM, Joerg Schilling wrote:
> John R Pierce <pierce at hogranch.com> wrote:
>
>> On 08/05/12 3:06 AM, Joerg Schilling wrote:
>>> Your claim is aproximately correct for NFSv2 (1988) but wrong for other NFS
>>> versions.
>> The server was using NFS V3/V4 in CentOS 6.2 earlier this year, and
>> various clients, including Solaris 10.   The problems were reported from
>> our overseas manufacturing operations so I only got them 3rd hand, and
>> don't know all the specifics.   In my lab I had only shared the root of
>> the file system as thats the model I use, but apparently operations
>> likes to have lots of different shares, MS Windows style.   This was a
>> 'stop production' kind of error, so the most expedient fix was to
>> manually specify the export ID.
> If you suffer from bugs in Linux filesystem implementations, you should make a
> bug report against the related code. Only a bug report ans a willing maintainer
> can help you.
>
> The problem you describe does not exist on Solaris nor on other systems with
> bug-free NFS and I know why I try to avoid Linux when NFS is important. It is a
> pity that after many years, there are still NFS problems in Linux.
>
> 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"


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

I discussed this problem on this list back in march, and got little 
useful feedback

I see related issues here.
http://oss.sgi.com/archives/xfs/2009-11/msg00161.html
so this problem has been known for awhile.

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.



-- 
john r pierce                            N 37, W 122
santa cruz ca                         mid-left coast