Hi,
I'm using kernel 2.4.20 under debian stable ('woody') and the
user-land nfs server, and I can't seem to traverse more than about 23 or
24 levels deep into a directory structure over NFS. Works fine on a local
ext2 or ext3 fs, but not when that fs is exported via the abovementioned
userland server. And it's definitely related to directory depth and
not PATHLEN because it fails even with single-char directory names for
the entire depth. So is this limit on the client, the server, or in the
protocol? And is it a bug or just a design limit?
Thanks for your help,
--pj
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Thursday 07 August 2003 22:56, Paul Jimenez wrote:
> Hi,
>
> I'm using kernel 2.4.20 under debian stable ('woody') and the
> user-land nfs server, and I can't seem to traverse more than about 23 or
> 24 levels deep into a directory structure over NFS. Works fine on a local
> ext2 or ext3 fs, but not when that fs is exported via the abovementioned
> userland server. And it's definitely related to directory depth and
> not PATHLEN because it fails even with single-char directory names for
> the entire depth. So is this limit on the client, the server, or in the
> protocol? And is it a bug or just a design limit?
>
> Thanks for your help,
>
Hi,
nfsv2 (nfsv3 is not supported by unfsd!) only allows 32 byte to decode the
entire nfs-filehandle, so if one would use the pathname encoded by characters
this would fail rather fast. IMHO all nfs-server use the inodes for
encrypting the path.
Well, unfsd has 28 bytes to encrypt the complete pathname via inodes (32 bit)
and hashtable into those 28 bytes. I guess that you have reached the
unfsd-limit.
The knfsd does different, as far as I understand it, the file handle only
consist of the file inode, the inode of the parent directory, a file creation
number and I think some other stuff. Anyway the 32 byte are sufficient here
to encode the pathname.
NFS-experts, please correct me if I'm wrong. Btw, I still don't understand how
the knfs-algorithm works, if the dentry-cache has no information about
parent-inode/inode (e.g. after a server reboot). How does the kernel figures
out the proper path in that case?
Best regards,
Bernd
PS: Paul, why do you insist on using unfsd. Knfsd does a much better job!
Well, there are a few exception for using unfsd, ClusterNFS is one of them,
but you have to be very carefull on using of it.
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs