Am Montag, 4. März 2013, 17:40:13 schrieb Hans-Peter Jansen:
> Hi,
>
> after upgrading the kernel on a server from 2.6.34 to 3.8.1 (x86-32), I
> suffer from a strange behavior of a larger directory, that a downgrade
> of the kernel cannot repair.
>
> The best way to reproduce the problem is cd into that directory and
> running "vi .". It should display a full directory listing, but it only
> displays a about dozen entries. Another way is just using bash tab
> completion (e.g. ls <tab><tab> should display a screenful of items, but
> only shows the very same dozen of entries. Userspace is quite old
> (openSUSE 11.1/i586, but I cannot upgrade to a newer userspace for a
> couple of reasons. OTOH, a simple ls displays the full list again,
[...]
> > # then it preceeds with getdents64 and fetches already fetched entries
>
> 27177 getdents64(3, {
> {d_ino=4303329151, d_off=78, d_type=DT_UNKNOWN, d_reclen=32, d_name="Black_Swan"}
Okay, this is the culprit: 0x1007F977F overflows 32 bit, although I
*never* mounted anything with inode64 option.
For some reason, the intermediate kernel 3.8.0 has used the inode64 version
by *default*. This breaks bash tab completion and vdr. After forcing the
inode32 option and copying some offenders away and back in place, the issue
vanishes.
Unlike stated in the XFS FAQs, openSUSE 11.1 *has* issues with inode64, and
even more so, if enabled by default.
I will hack up a script now, that copes with this mess.
Cheers,
Pete
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
