John R Pierce pierce@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?
Jörg