On Fri, Mar 31, 2000 at 09:00:02AM -0600, lord@xxxxxxx wrote:
> >
> >
> > When doing a ls from a client on a exported XFS in a big directory
> > (e.g. linux/fs/xfs) it gets into an endless loop and runs until the
> > memory of the ls is exhausted. It shows the first entries normally
> > and then returns one again and again.
> >
> >
> > -Andi
> >
>
>
> I have my suspicions about the readdir interface at the moment, I have seen
> rm -r -f miss a file. Also Suse just won another prize, 'First to NFS export
The file system was quiet here, so it must have been some basicproblem
to resynchronize.
You seem not the only one with rm -rf problems, see the current
"dentry pinning down" thread on linux-kernel. reiserfs and ext2 had quite some
problems with verifying the f_pos in readdir in the past too (upto
exploitable root holes @/)
This happened with the kernel nfsd BTW, I forgot to mention that.
> an XFS filesystem from Linux'! We have been busy making this thing stay up at
> all, kernel builds inside XFS only started working this week.
Heh :-)
My gratulations for this archivement.
>
> We found problems between the Linux glibc getdents call running over NFS
> to an XFS filesystem on Irix - which could be related, in that case it
> managed to miss some entries. The getdents library call does this heuristic
> to prune down the user's request size (since kernel getdents are bigger than
> glibc getdents structures). In the case where it guesses wrong it does an
> lseek backwards, this gets confused by the lseek offsets.
It looked more like it simply lost track on a directory
block boundary or similar.
-Andi
|