Bug 220451
Summary: | NFS to Tru64 badly broken | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Steve Dickson <steved> | ||||
Component: | kernel | Assignee: | Steve Dickson <steved> | ||||
Status: | CLOSED RAWHIDE | QA Contact: | Brian Brock <bbrock> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 6 | CC: | alfredo.maria.ferrari, dancy, davej, deknuydt, ipesando, matthew.amos, ole.h.nielsen, rgarth, staubach, wtogami | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | i686 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2007-08-29 23:46:50 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | 211293 | ||||||
Bug Blocks: | |||||||
Attachments: |
|
Description
Steve Dickson
2006-12-21 13:11:33 UTC
I have this problem as well. We have two Tru64 5.1 machines and two Tru64 4.0 machines. The problem only occurs for us w/ the 5.1 machines. I capture and examined some packet traces and I don't see anything wrong w/ the transactions themselves. The kernel just seems to be doing the wrong thing w/ the results. Linux quadra.franz.com 2.6.18-1.2869.fc6 #1 SMP Wed Dec 20 14:51:34 EST 2006 x86_64 x86_64 x86_64 GNU/Linux Sample bad behavior: [root@quadra /]# mount epsilon:/acl /mnt [root@quadra /]# stat /mnt/dancy File: `/mnt/dancy' Size: 8192 Blocks: 16 IO Block: 4096 directory Device: 3fh/63d Inode: 156057 Links: 3 Access: (0755/drwxr-xr-x) Uid: ( 443/ dancy) Gid: ( 50/ ftp) Access: 2007-01-24 15:02:25.592081000 -0800 Modify: 2006-07-18 13:15:34.169051000 -0700 Change: 2006-07-18 13:15:34.169051000 -0700 [root@quadra /]# ls /mnt/dancy total 24 8 ./ 8 ../ 8 acl-64/ [root@quadra /]# stat /mnt/dancy/acl-64 File: `/mnt/dancy/acl-64' Size: 8192 Blocks: 16 IO Block: 4096 directory Device: 3fh/63d Inode: 95568 Links: 32 Access: (0755/drwxr-xr-x) Uid: ( 443/ dancy) Gid: ( 50/ ftp) Access: 2007-01-24 01:12:59.248123000 -0800 Modify: 2006-05-18 09:03:52.744025000 -0700 Change: 2006-05-18 09:03:52.744025000 -0700 [root@quadra /]# ls /mnt/dancy/acl-64 ls: /mnt/dancy/acl-64: Not a directory [root@quadra /]# umount /mnt Clearly bogus. Packet traces available upon request. 2.6.19-1.2911.fc6 does not fix the problem. I guess by now RedHat must have given up on this one? No! I was hoping that HP was going to bring Tru64 to this years Connectathon... Unfortunately that was not the case... so I asked the HP people that did attend to send me the name of the support person that could help with this... I also had a conversion with the upstream NFS maintainer (who also attended Connectathon) and we both are a bit stump on this one... With the 2.6.20 kernel, there has been some readdir that might address this problem... I'm looking into that now... You'll note that the FS-Cache patches are longer the latest FC6 kernel... so it takes them out of play... Created attachment 149293 [details]
Purposed Patch
It turns out that this is not a Linux client problem at all!
Although its true Linux server do fail against Tru64,
but they fail because Tru64 servers are sending different
fsids for the same filesystem.
Now it appears only the Linux client actually looks
at the values of fsids being returned and that
started with a patch back in the Linux 2.6.12 time frame.
So I have a feeling the Tru64 servers have always been
broken...
For the gory details see the usptream posting
(I would post the link but as usual sourceforge.net down)
So the attached patch does seem to fix the problem,
but its not clear how accepting upstream will be
of this patch...
Thanks Steve. I'm keeping my fingers crossed and sacrificing a chicken. Here is the upstream discussion... http://sourceforge.net/mailarchive/forum.php?thread_id=31756540&forum_id=4930 It appears this patch will not be accepted. But I would suggest you use this patch until I can figure something else out... It is true, that there is simply no way HP will fix this problem, correct? HP is no longer sending out updates right? As far as I know no chance to get an update from HP. It is even hard to get hardware reapirs (the last one was nonsensically expensive). BTW thanks for all your efforts Just curious... is there a way to turn off READDIRPLUS support on Tru64 servers? With all due respect to Tru64 and HP, perhaps it is time to consider a replacement? :-) Tru64 does still appear to be maintained to some degree: http://h30097.www3.hp.com/pdf/Tru64_Roadmap_Current.pdf (In reply to comment #8) > Just curious... is there a way to turn off READDIRPLUS > support on Tru64 servers? Yes! The following worked for me. There is probably some better way to do this so that it remains permanent across boots, but I haven't figured it out yet: ladebug -k assign doreaddirplus=0 quit If anyone is interested, I have hacked up a new nfs_server.mod kernel module for Tru64 which fixes the bug. I have it deployed on a local system and it works fine. I built it against a host that identifies itself as Tru64 V5.1B (Rev: 2650). It can probably be adjusted for other versions as well. *** Bug 217705 has been marked as a duplicate of this bug. *** Regarding Comment #11 I have some further advice: You may not have "ladebug" installed on your Tru64 server, but probably you have /usr/bin/dbx. You may then modify the "doreaddirplus" variable until the next reboot by: # dbx -k /vmunix (dbx) assign doreaddirplus=0 (dbx) quit If you want the change to be persistent across reboots do: # dbx -k /vmunix (dbx) patch doreaddirplus=0 (dbx) quit If you upgrade the kernel this will have to be repeated. We have verified that this workaround solves the NFS problem with a Tru64 NFS server and a RHEL5 Linux NFS client. Fixed in nfs-utils-1.0.10-10.fc6 by added the -o nordirplus mount option which will have the kernel support in the next kernel update. |