All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Hans-Peter Jansen <hpj@urpla.net>
Cc: xfs@oss.sgi.com
Subject: Re: strange behavior of a larger xfs directory
Date: Tue, 5 Mar 2013 10:18:52 +1100	[thread overview]
Message-ID: <20130304231852.GO26081@dastard> (raw)
In-Reply-To: <5347920.zaxHybjLeK@xrated>

On Mon, Mar 04, 2013 at 11:55:40PM +0100, Hans-Peter Jansen wrote:
> 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.

Wonderful. Report a bug to OpenSuSE and get userspace fixed. It's
only a matter of time before btrfs and ext4 users start reporting
the same problem, as they also use 64 bit inode numbers....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2013-03-04 23:18 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-04 16:40 strange behavior of a larger xfs directory Hans-Peter Jansen
2013-03-04 22:55 ` Hans-Peter Jansen
2013-03-04 23:18   ` Dave Chinner [this message]
2013-03-04 23:05 ` Dave Chinner
2013-03-05 20:32   ` Hans-Peter Jansen
2013-03-05 22:29     ` Dave Chinner
2013-03-05 23:48       ` Hans-Peter Jansen
2013-03-06  0:57         ` Dave Chinner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130304231852.GO26081@dastard \
    --to=david@fromorbit.com \
    --cc=hpj@urpla.net \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.