Kris Buggenhout wrote:
>> Thomas Graichen wrote:
>> even one more thing for the FAQ: are there any problems to expect then
>> running NFS on top of XFS (like the problems reiserfs has to get the
>> 32bit nfsv2 handle mapped to the 64bit identifier) ? Anyone tried
>> it in detail ? (i tried it lightly and had no problems - but my
>> tests were not very deep)
>>
>> If its anything like the IRIX version,
>> XFS will cope until the number of entry's in a directory exceeds a certain
>> number IRIX has the ability to map it in the nfs code (i think) when U export
>> and are going te expect trouble, U export it with the option 32bitclients
>> I dont know how it relates to the linux version ...
>> with reiserfs it will always try to use a 64bit number ...
>> which confuses the nfs ...
There are two separate issues here:
1. XFS inode numbers are actually 64 bit - and the linux inode number is 32
bits,
this only becomes an issue when the filesystem size exceeds 2 Tbytes, which
is
when the top 32 bits of the inode number starts getting used (the number is
really a disk address)
This is a general problem in Linux - only the bottom half of the inode
number
is visible above the VFS. Since NFS just encodes the inode number into its
file handle, and is the only caller of iget above the vfs level, it will
break
once this size boundary is crossed. Reiserfs has similar issues in this
area.
An ideal solution from our point of view would be to move the file handle
contstruction and interpretation below the VFS layer - NFS would ask the
VFS to build a handle, and to return the inode associated with a handle -
this
is the norm in most Unix systems I have seen.
2. Directory hash values - the original directory format in XFS returned a
directory
offset which was actually a 64 bit hash value - the NFS protocol chops this
down
to 32 bits. With this truncation there is a possibility of getdents calls
starting
to loop in some directories where the hash value if several entries is the
same,
skipping entries has also been seen.
XFS has a newer directory format (the default on Linux) which will not
exhibit this
problem since the directory offset is now actually an offset - so until a
directory
gets REALLY big, 32 bits is enough.
Moving a filesystem from irix which was built with the old directory format
will
potentially expose this problem, filesystems built on Linux will work -
unless you
tell mkfs to use the old format.
Steve
|