[Top] [All Lists]

Re: strange behavior of a larger xfs directory

To: Hans-Peter Jansen <hpj@xxxxxxxxx>
Subject: Re: strange behavior of a larger xfs directory
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Wed, 6 Mar 2013 11:57:45 +1100
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <1517139.CltWl8VXzZ@xrated>
References: <4300208.uZ6HVTycB6@xrated> <8026381.3dEJ1E4pzL@xrated> <20130305222941.GP26081@dastard> <1517139.CltWl8VXzZ@xrated>
User-agent: Mutt/1.5.21 (2010-09-15)
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

> 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....


Dave Chinner

<Prev in Thread] Current Thread [Next in Thread>