I just upgraded one of my machines to Fedora Core 2, including
kernel 2.6.5. I found myself bitten on the bum by a bug I thought
had expired long ago, namely the Irix server readdir bug, or
32/64-bit cookie problem.
Therefore, I thought I should let you folks know that this problem
is still there, apparently.
I searched the LKML archives for (irix OR sgi) and nfs: the most
recent relevant postings seem to be 2 years ago
http://www.uwsg.iu.edu/hypermail/linux/kernel/0204.1/0707.html
http://www.uwsg.iu.edu/hypermail/linux/kernel/0204.2/0163.html
It seems the relevant patch
http://www.fys.uio.no/~trondmy/src/2.4.18/linux-2.4.18-seekdir.dif
was never incorporated in the mainstream kernel; however, Red Hat
did incorporate a similar patch (called, I believe,
linux-2.4.18-irixnfs.patch) in the later 2.4 kernel RPMS. However,
it seems that this has been omitted from the 2.6 kernels in Fedora.
So, I have the old problem: in a directory listing from an NFS
directory mounted from an Irix server, some entries may be
missing.
So, my question is: what happened to this patch? Is there a
2.6 version available somewhere on the net? Was it not
incorporated into the mainstream kernel because it is not the
"right thing" to do (and maybe there is no "right thing" until
we are all running on 64 bits)? If this is the opinion of
the kernel developers I shall chase Red Hat to see if they can
resurrect it when 2.6 kernels appear in their RHEL product.
Some of us unfortunately still need to interoperate with Irix
and other strange systems :-)
If the list is interested, I have "sort of" ported the patch
to Linux 2.6.6 myself - just before I left work this afternoon;
It seems functional, but I need to have another look on my network
at work (where I have the SGI system) before I post it; there may be
other bits that need patching, though I hope my minimal patch will
suffice.
Please CC: to me, as I am not subscribed to the list yet.
Peter Wainwright wrote, On 6/16/2004 11:52 AM:
> I just upgraded one of my machines to Fedora Core 2, including
> kernel 2.6.5. I found myself bitten on the bum by a bug I thought
> had expired long ago, namely the Irix server readdir bug, or
> 32/64-bit cookie problem.
>
> It seems the relevant patch
> http://www.fys.uio.no/~trondmy/src/2.4.18/linux-2.4.18-seekdir.dif
> was never incorporated in the mainstream kernel; however, Red Hat
> did incorporate a similar patch (called, I believe,
> linux-2.4.18-irixnfs.patch) in the later 2.4 kernel RPMS. However,
> it seems that this has been omitted from the 2.6 kernels in Fedora.
> So, I have the old problem: in a directory listing from an NFS
> directory mounted from an Irix server, some entries may be
> missing.
>
> So, my question is: what happened to this patch? Is there a
> 2.6 version available somewhere on the net? Was it not
> incorporated into the mainstream kernel because it is not the
> "right thing" to do (and maybe there is no "right thing" until
> we are all running on 64 bits)? If this is the opinion of
> the kernel developers I shall chase Red Hat to see if they can
> resurrect it when 2.6 kernels appear in their RHEL product.
> Some of us unfortunately still need to interoperate with Irix
> and other strange systems :-)
>
> If the list is interested, I have "sort of" ported the patch
> to Linux 2.6.6 myself - just before I left work this afternoon;
> It seems functional, but I need to have another look on my network
> at work (where I have the SGI system) before I post it; there may be
> other bits that need patching, though I hope my minimal patch will
> suffice.
I ran across the same problem the other day. Maybe someone on the nfs
list have a better idea on what the proper solution is. My temporary
solution was to go back to a 2.4 kernel with the seekdir.dif patch.
Looking at Trond's 2.6 NFS patches, there doesn't appear to be any sort
of seekdir patch for those kernels.
As I understand it the real problem is actually in glibc. I have to
double check, but I think the software which showed this bug when I
experienced it on FC2 was statically linked with an older version of
glibc. I can't seem to reproduce it using `ls` which I remember being
able to last time I had the problem so that would explain it. What
software showed the problem for you?
See this message from the nfs list. There is more data in the archives
if you look.
http://marc.theaimsgroup.com/?l=linux-nfs&m=105158098101612&w=2
-Dave
On Thu, Jun 17, 2004 at 02:26:32AM -0700, David Rees wrote:
> Peter Wainwright wrote, On 6/16/2004 11:52 AM:
> >I just upgraded one of my machines to Fedora Core 2, including
> >kernel 2.6.5. I found myself bitten on the bum by a bug I thought
> >had expired long ago, namely the Irix server readdir bug, or
> >32/64-bit cookie problem.
>
> glibc. I can't seem to reproduce it using `ls` which I remember being
> able to last time I had the problem so that would explain it. What
> software showed the problem for you?
You can see the different if you do `ls dir` and `ls dir/*`. Typically
the shell will use readdir and ls will use getdents, IIRC. I was using
the test case readdir01 from LTP.
--
Nate Straz [email protected]
sgi, inc http://www.sgi.com/
Linux Test Project http://ltp.sf.net/
On Wed, Jun 16, 2004 at 07:52:06PM +0100, Peter Wainwright wrote:
> I just upgraded one of my machines to Fedora Core 2, including
> kernel 2.6.5. I found myself bitten on the bum by a bug I thought
> had expired long ago, namely the Irix server readdir bug, or
> 32/64-bit cookie problem.
>
> Therefore, I thought I should let you folks know that this problem
> is still there, apparently.
IIRC this was fixed on the IRIX side a while ago. What IRIX version
do you run?
On Thu, 2004-06-17 at 14:44, Christoph Hellwig wrote:
> On Wed, Jun 16, 2004 at 07:52:06PM +0100, Peter Wainwright wrote:
> > I just upgraded one of my machines to Fedora Core 2, including
> > kernel 2.6.5. I found myself bitten on the bum by a bug I thought
> > had expired long ago, namely the Irix server readdir bug, or
> > 32/64-bit cookie problem.
> >
> > Therefore, I thought I should let you folks know that this problem
> > is still there, apparently.
>
> IIRC this was fixed on the IRIX side a while ago. What IRIX version
> do you run?
>
Not very old, it's 6.5.21. And I do have -32bitclients
in my /etc/exports.
BTW, I just found an old patch I made for glibc 2.2 to
fix this (or a similar) problem. Maybe that's a better
place for a fix
Peter Wainwright
Peter Wainwright wrote:
> On Thu, 2004-06-17 at 14:44, Christoph Hellwig wrote:
>>
>>IIRC this was fixed on the IRIX side a while ago. What IRIX version
>>do you run?
>>
>
>
> Not very old, it's 6.5.21. And I do have -32bitclients
> in my /etc/exports.
>
> BTW, I just found an old patch I made for glibc 2.2 to
> fix this (or a similar) problem. Maybe that's a better
> place for a fix
>
Part of the fix for these issues with Irix NFS was version 2
directories in XFS, this made directory offsets in XFS into
real offsets rather than 64 bit hash values.
If your filesystem is old enough, it will have version 1
directories - and the only conversion process is to do
a dump/mkfs/restore.
xfs_growfs -n /mntpnt will report the directory version
as naming=1 or naming=2 if I recall correctly.
Steve
On Thu, 2004-06-17 at 10:26, David Rees wrote:
>
> As I understand it the real problem is actually in glibc. I have to
> double check, but I think the software which showed this bug when I
> experienced it on FC2 was statically linked with an older version of
> glibc. I can't seem to reproduce it using `ls` which I remember being
> able to last time I had the problem so that would explain it. What
> software showed the problem for you?
The Gnome configuration daemon, gconfd-2. My desktop configuration
reverted to the default because this program could not find
~/.gconf/apps/panel/profiles/default on an NFS-mounted home
directory.
Peter Wainwright
>
> See this message from the nfs list. There is more data in the archives
> if you look.
> http://marc.theaimsgroup.com/?l=linux-nfs&m=105158098101612&w=2
>
> -Dave
On Thu, 2004-06-17 at 18:54, Steve Lord wrote:
>
> Part of the fix for these issues with Irix NFS was version 2
> directories in XFS, this made directory offsets in XFS into
> real offsets rather than 64 bit hash values.
>
> If your filesystem is old enough, it will have version 1
> directories - and the only conversion process is to do
> a dump/mkfs/restore.
>
> xfs_growfs -n /mntpnt will report the directory version
> as naming=1 or naming=2 if I recall correctly.
>
> Steve
Thanks, that explains it. The filesystem in question
indeed has naming=1. Now I just have to work out whether it is
worth the effort of conversion or whether I can live with a
kludged linux client (glibc or kernel).
Thanks to all who replied...
Peter