* getcwd() returns wrong pathname @ 2002-12-03 2:45 miyoshi 2002-12-03 3:34 ` Neil Brown 0 siblings, 1 reply; 6+ messages in thread From: miyoshi @ 2002-12-03 2:45 UTC (permalink / raw) To: nfs 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 <miyoshi@hpc.bs1.fc.nec.co.jp> 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 - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: getcwd() returns wrong pathname 2002-12-03 2:45 getcwd() returns wrong pathname miyoshi @ 2002-12-03 3:34 ` Neil Brown 2002-12-03 4:47 ` miyoshi 0 siblings, 1 reply; 6+ messages in thread From: Neil Brown @ 2002-12-03 3:34 UTC (permalink / raw) To: miyoshi; +Cc: nfs On Tuesday December 3, miyoshi@hpc.bs1.fc.nec.co.jp 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 - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: getcwd() returns wrong pathname 2002-12-03 3:34 ` Neil Brown @ 2002-12-03 4:47 ` miyoshi 2002-12-03 5:41 ` Neil Brown 0 siblings, 1 reply; 6+ messages in thread From: miyoshi @ 2002-12-03 4:47 UTC (permalink / raw) To: neilb; +Cc: nfs, tanaka-h, hoshi, yamasita, fuku, lgml 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 <miyoshi@hpc.bs1.fc.nec.co.jp> 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 - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: getcwd() returns wrong pathname 2002-12-03 4:47 ` miyoshi @ 2002-12-03 5:41 ` Neil Brown 2002-12-03 10:16 ` James Pearson 2002-12-03 10:49 ` miyoshi 0 siblings, 2 replies; 6+ messages in thread From: Neil Brown @ 2002-12-03 5:41 UTC (permalink / raw) To: miyoshi; +Cc: nfs, tanaka-h, hoshi, yamasita, fuku, lgml On Tuesday December 3, miyoshi@hpc.bs1.fc.nec.co.jp 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 - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: getcwd() returns wrong pathname 2002-12-03 5:41 ` Neil Brown @ 2002-12-03 10:16 ` James Pearson 2002-12-03 10:49 ` miyoshi 1 sibling, 0 replies; 6+ messages in thread From: James Pearson @ 2002-12-03 10:16 UTC (permalink / raw) To: miyoshi; +Cc: nfs, tanaka-h, hoshi, yamasita, fuku, lgml 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, miyoshi@hpc.bs1.fc.nec.co.jp 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 - NFS@lists.sourceforge.net > 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 - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: getcwd() returns wrong pathname 2002-12-03 5:41 ` Neil Brown 2002-12-03 10:16 ` James Pearson @ 2002-12-03 10:49 ` miyoshi 1 sibling, 0 replies; 6+ messages in thread From: miyoshi @ 2002-12-03 10:49 UTC (permalink / raw) To: neilb; +Cc: nfs, tanaka-h, hoshi, yamasita, fuku, lgml 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 <miyoshi@hpc.bs1.fc.nec.co.jp> 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 - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2002-12-03 10:47 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2002-12-03 2:45 getcwd() returns wrong pathname miyoshi 2002-12-03 3:34 ` Neil Brown 2002-12-03 4:47 ` miyoshi 2002-12-03 5:41 ` Neil Brown 2002-12-03 10:16 ` James Pearson 2002-12-03 10:49 ` miyoshi
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.