> jansen wrote:
>
> > Russell Cattelan wrote:
> >
> > [stuff deleted]
> >
> > > The pending release of XFS 1.0.1 will be RH7.1 and 2.4.4 based, and will
> > > be based primarily on what is in the development tree... once the list
> > > or problems has been whittled down.
> >
> > [stuff deleted]
> >
> > I realize that you all have a great many other things to do and fixing
> > non-XFS related kernel bugs is not your focus but having said that
> > I'd really like to see the patch for the IRIX -> Linux NFS directory bug
> > (where files are missing when doing an "ls *" in a directory served via
> > NFS from an IRIX server) be included in the next XFS release. I believe
> > this was mentioned on the list about three weeks ago. There is a patch
> > that appears to fix this in the 1.0 release (with a little modification
> > since the patch is for stock 2.4.2). I believe there was also a patch
> > for 2.4.4 but I haven't had the time to try it.
> >
> > This bug initially stopped me from installing the 1.0 release on all
> > my Linux machines because we have a fair number of IRIX machines
> > serving files via NFS and this bug caused a whole host of problems.
> >
> > The patches for this bug can be found at:
> >
> >
>
> wasnt there a workaround ... by exporting the fs on the irix machine with -o
> 32bitclients option ?
>
> I remember I had to do this to be able to mount irix nfs shares on linux'en
> and Solaris 2.5 machines.
> without strange problems like not seeing all files in an ls on the nfs
> client.
>
> I had to do this because our main file server was an Origin200 ... :)
>
> could be a temp solution to not hold back on xfs ... ;)
Well, 32 bits is not quite low enough, glibc only likes 31 bits in the
lseek offset, this is the problem. I talked to the glibc maintainer and
he will not budge on this one. Yes we could package the patch if we do
a respin.
Steve
|