Hello,
I'm having problems with linux NFS. Here is my situation.
When mounting remote linux NFS filesystem to /mnt/xxx/yyy,
pwd or getcwd() sometimes returns imcomplete pathname.
We are using linux kernel 2.4.17.
% mount linuxserver:/mnt/xxx /mnt/xxx
% cd /mnt/xxx/yyy
% pwd
/xxx/yyy <--- should be /mnt/xxx/yyy
Is there any ideas or fixes?
I'll be very gratefull to any suggestion.
Regards,
--
MIYOSHI Kazuto <[email protected]>
HPC Operating System Group, 1st Computers Software Division,
Computers Software Operations Unit, NEC Solutions.
-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Tuesday December 3, [email protected] wrote:
>
> Hello,
>
> I'm having problems with linux NFS. Here is my situation.
>
> When mounting remote linux NFS filesystem to /mnt/xxx/yyy,
> pwd or getcwd() sometimes returns imcomplete pathname.
> We are using linux kernel 2.4.17.
>
> % mount linuxserver:/mnt/xxx /mnt/xxx
> % cd /mnt/xxx/yyy
> % pwd
> /xxx/yyy <--- should be /mnt/xxx/yyy
>
> Is there any ideas or fixes?
> I'll be very gratefull to any suggestion.
Are both client and server Linux?
What does '/bin/pwd' say?
What does
ls -l /proc/self/cwd
say?
NeilBrown
-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Hi,
> > I'm having problems with linux NFS. Here is my situation.
> >
> > When mounting remote linux NFS filesystem to /mnt/xxx/yyy,
> > pwd or getcwd() sometimes returns imcomplete pathname.
> > We are using linux kernel 2.4.17.
> >
> > % mount linuxserver:/mnt/xxx /mnt/xxx
> > % cd /mnt/xxx/yyy
> > % pwd
> > /xxx/yyy <--- should be /mnt/xxx/yyy
> >
> > Is there any ideas or fixes?
> > I'll be very gratefull to any suggestion.
>
> Are both client and server Linux?
Thank you for your response and sorry for not providing enough
information.
Server is Linux, but client is not linux (NEC enhanced UNIX and HP-UX)
Also I found bugzilla entry which says about same problem on IRIX.
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=46705
It may be a problem or an incompatibility of those unices,
but if it is a typical incompatibility, I want to know the root
cause of it.
I will be able to collect information from client and/or server,
but what information? Tcpdump output? Kernel trace?
Any suggestions/help for investigatation are welcome.
> What does '/bin/pwd' say?
> What does
> ls -l /proc/self/cwd
> say?
I will check those information on those unices.
--
MIYOSHI Kazuto <[email protected]>
HPC Operating System Group, 1st Computers Software Division,
Computers Software Operations Unit, NEC Solutions.
-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Tuesday December 3, [email protected] wrote:
>
> Hi,
>
> > > I'm having problems with linux NFS. Here is my situation.
> > >
> > > When mounting remote linux NFS filesystem to /mnt/xxx/yyy,
> > > pwd or getcwd() sometimes returns imcomplete pathname.
> > > We are using linux kernel 2.4.17.
> > >
> > > % mount linuxserver:/mnt/xxx /mnt/xxx
> > > % cd /mnt/xxx/yyy
> > > % pwd
> > > /xxx/yyy <--- should be /mnt/xxx/yyy
> > >
> > > Is there any ideas or fixes?
> > > I'll be very gratefull to any suggestion.
> >
> > Are both client and server Linux?
>
> Thank you for your response and sorry for not providing enough
> information.
>
> Server is Linux, but client is not linux (NEC enhanced UNIX and HP-UX)
> Also I found bugzilla entry which says about same problem on IRIX.
>
> http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=46705
>
> It may be a problem or an incompatibility of those unices,
> but if it is a typical incompatibility, I want to know the root
> cause of it.
The root cause is that pwd works but walking up a path of ..,
../.. etc finding the name of each component by reading through the
directory for a name which matches the inode number found by statting
".." from below (does that make sense?)
Anyway, this requires '..' to work reliably, particularly over the
mount point.
On non-linux unixes, the client sends a 'lookup("..")' request to the
fileserver. In order for the client to recognise the mount point on
the way up a path of ".." lookups, the filehandle returned by
lookup(".."), but be exactly the filehandle that was obtained by the
mount request.
However, HP-UX (At least) does this comparison wrongly. In NFSv3,
filehandles are variable length, up to 64 bytes. HP-UX however will
always compare at least 32 bytes (the size of an NFSv2 filehandle).
If the filehandle returned by the server is less than 32 bytes (which
is the case with the Linux nfs server) then some of those 32 bytes
compared will be random garbage, and the comparison will fail. So pwd
never finds the mountpoint as it walks up the chain of "..", and gets
confused.
Apparently HP were going to release a fix for this, but I don't know
if they have.
One work-around is to use NFSv2. It uses fixed sized (zero-padded)
filehandles and so doesn't suffer this problem.
It is possible to hack the Linux nfs server to return a minimum
filehandle of 32 bytes, but I don't want that hack in the standard
kernel.
NeilBrown
-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
IRIX clients used to suffer in a similar way - a couple of
workarounds/patches for the Linux knfsd server are suggested in the NFS
HOW-TO at:
http://nfs.sourceforge.net/nfs-howto/interop.html#IRIX
Unfortunately the links mentioned are out-of-date - should now be:
http://oss.sgi.com/projects/xfs/mail_archive/200110/msg00006.html
http://marc.theaimsgroup.com/?l=linux-nfs&m=99743544531724&w=2
I understand these patches work for HP-UX clients as well.
James Pearson
Neil Brown wrote:
>
> On Tuesday December 3, [email protected] wrote:
> >
> > Hi,
> >
> > > > I'm having problems with linux NFS. Here is my situation.
> > > >
> > > > When mounting remote linux NFS filesystem to /mnt/xxx/yyy,
> > > > pwd or getcwd() sometimes returns imcomplete pathname.
> > > > We are using linux kernel 2.4.17.
> > > >
> > > > % mount linuxserver:/mnt/xxx /mnt/xxx
> > > > % cd /mnt/xxx/yyy
> > > > % pwd
> > > > /xxx/yyy <--- should be /mnt/xxx/yyy
> > > >
> > > > Is there any ideas or fixes?
> > > > I'll be very gratefull to any suggestion.
> > >
> > > Are both client and server Linux?
> >
> > Thank you for your response and sorry for not providing enough
> > information.
> >
> > Server is Linux, but client is not linux (NEC enhanced UNIX and HP-UX)
> > Also I found bugzilla entry which says about same problem on IRIX.
> >
> > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=46705
> >
> > It may be a problem or an incompatibility of those unices,
> > but if it is a typical incompatibility, I want to know the root
> > cause of it.
>
> The root cause is that pwd works but walking up a path of ..,
> ../.. etc finding the name of each component by reading through the
> directory for a name which matches the inode number found by statting
> ".." from below (does that make sense?)
>
> Anyway, this requires '..' to work reliably, particularly over the
> mount point.
>
> On non-linux unixes, the client sends a 'lookup("..")' request to the
> fileserver. In order for the client to recognise the mount point on
> the way up a path of ".." lookups, the filehandle returned by
> lookup(".."), but be exactly the filehandle that was obtained by the
> mount request.
>
> However, HP-UX (At least) does this comparison wrongly. In NFSv3,
> filehandles are variable length, up to 64 bytes. HP-UX however will
> always compare at least 32 bytes (the size of an NFSv2 filehandle).
> If the filehandle returned by the server is less than 32 bytes (which
> is the case with the Linux nfs server) then some of those 32 bytes
> compared will be random garbage, and the comparison will fail. So pwd
> never finds the mountpoint as it walks up the chain of "..", and gets
> confused.
>
> Apparently HP were going to release a fix for this, but I don't know
> if they have.
>
> One work-around is to use NFSv2. It uses fixed sized (zero-padded)
> filehandles and so doesn't suffer this problem.
>
> It is possible to hack the Linux nfs server to return a minimum
> filehandle of 32 bytes, but I don't want that hack in the standard
> kernel.
>
> NeilBrown
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Get the new Palm Tungsten T
> handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
> _______________________________________________
> NFS maillist - [email protected]
> https://lists.sourceforge.net/lists/listinfo/nfs
-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Hi,
> The root cause is that pwd works but walking up a path of ..,
> ../.. etc finding the name of each component by reading through the
> directory for a name which matches the inode number found by statting
> ".." from below (does that make sense?)
Yes, our UNIX guys also explained me like that.
> However, HP-UX (At least) does this comparison wrongly. In NFSv3,
> filehandles are variable length, up to 64 bytes. HP-UX however will
> always compare at least 32 bytes (the size of an NFSv2 filehandle).
> If the filehandle returned by the server is less than 32 bytes (which
> is the case with the Linux nfs server) then some of those 32 bytes
> compared will be random garbage, and the comparison will fail. So pwd
> never finds the mountpoint as it walks up the chain of "..", and gets
> confused.
And our UNIX team agreed with the story above. Thanks for your explanation.
> Apparently HP were going to release a fix for this, but I don't know
> if they have.
>
> One work-around is to use NFSv2. It uses fixed sized (zero-padded)
> filehandles and so doesn't suffer this problem.
>
> It is possible to hack the Linux nfs server to return a minimum
> filehandle of 32 bytes, but I don't want that hack in the standard
> kernel.
I agree with you that it can be done on client side.
But if we need HP-UX compliance :-< we must patch or hack our kernel.
> IRIX clients used to suffer in a similar way - a couple of
> workarounds/patches for the Linux knfsd server are suggested in the NFS
> HOW-TO at:
>
> http://nfs.sourceforge.net/nfs-howto/interop.html#IRIX
Hmm, I've never thought that the phenomena are already described in
HOW-TO...
Anyhow, thank you two guys. Your comment makes our situations clear.
Regards,
--
MIYOSHI Kazuto <[email protected]>
HPC Operating System Group, 1st Computers Software Division,
Computers Software Operations Unit, NEC Solutions.
-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs