strange behavior of a larger xfs directory

[Dave Chinner]

On Wed, Mar 06, 2013 at 12:48:25AM +0100, Hans-Peter Jansen wrote:
> Am Mittwoch, 6. März 2013, 09:29:41 schrieb Dave Chinner:
> > On Tue, Mar 05, 2013 at 09:32:02PM +0100, Hans-Peter Jansen wrote:
> > attr_list and attr_multi are supplied by libattr, you should not
> > need the *by_handle variants at all - they are special sauce used by
> > xfsdump, not xfs_reno....
> 
> Ahh, I see. These interfaces cannot be exercised much, given that google 
> didn't relate them to libattr prominently..

Attributes are not widely used by applications for some reason...

> Hmm, any idea on how xfs can be tricked into generating 64 bit inodes without 
> the need to create an excessive big test fs, or is this an accepted practice?

The usual trick is to use a sparse loopback device and create the
filesystem on that. see, for example, xfstests 078, where it is
testing growfs on filesystems up to 16TB in size on a loopback
device...

> Note to myself: xfs_reno could use some mount option check. Forgot to remount 
> one partition with inode32 and, consequently, moved the offending inodes to 
> another 64 bit value..

I'd just use a wrapper script that checked /proc/mounts for the
inode64 flag being set first....

....

> Index: b/configure.ac
> ===================================================================
> --- a/configure.ac
> +++ b/configure.ac
....

The patch looks sane - can you add a commit description and s
Signed-off-by line to it, and then we can use it directly....

Cheers,

Dave.
-- 
Dave Chinner
david at fromorbit.com