[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 09:29:41 +1100
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <8026381.3dEJ1E4pzL@xrated>
References: <4300208.uZ6HVTycB6@xrated> <20130304230527.GM26081@dastard> <8026381.3dEJ1E4pzL@xrated>
User-agent: Mutt/1.5.21 (2010-09-15)
On Tue, Mar 05, 2013 at 09:32:02PM +0100, Hans-Peter Jansen wrote:
> Am Dienstag, 5. März 2013, 10:05:27 schrieb Dave Chinner:
> > On Mon, Mar 04, 2013 at 05:40:13PM +0100, Hans-Peter Jansen wrote:
> > Second solution: Run 3.8.1, make sure you mount with inode32, and
> > then run the xfs_reno tool mentioned on this page:
> >
> > http://xfs.org/index.php/Unfinished_work
> > 
> > to find all the inodes with inode numbers larger than 32
> > bits and move them to locations with smaller inode numbers.
> Okay, I would like to take that route.
> I've updated the xfsprogs, xfsdump and xfstests packages in my openSUSE build 
> service repo home:frispete:tools to current versions today, and plan to 
> submit 
> them to Factory. openSUSE is always lagging in this area.
> I've tried to include a build of the xfs_reno tool in xfsprogs, since, as you 
> mentioned, others might have a similar need soon. Unfortunately I failed so 
> far, because it is using some attr_multi and attr_list interfaces, that 
> aren't 
> part of the xfsprogs visible API anymore. Only the handle(3) man page refers 
> to them.
> Attached is my current state: I've relocated the patch to xfsprogs 3.1.9, 
> because it already carries all the necessary headers (apart from attr_multi 
> and attr_list). The attr interfaces seem to be collected in libhandle now, 
> hence I've added it to the build. 

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

> +TOPDIR = ..
> +include $(TOPDIR)/include/builddefs
> +
> +LTCOMMAND = xfs_reno
> +CFILES = xfs_reno.c

The patch assumes that libattr has been found by autoconf and set up
in $(LIBATTR), but xfsprogs does not currently use libattr and hence
that variable isn't set up. Therefore this line is a no-op:


Change it to:

LLDLIBS = -lattr

And the xfs_reno should then link.

BTW, if you want extra points and add the autoconf magic to the
patch, copy it from the xfsdump tree. The places you need to copy
from are:

$ git grep -l LIBATTR |grep -v Makefile

And for even more bonus points, you could write a basic xfstest that
creates a bunch of 64 bit inodes and then runs xfs_reno on it and
checks that they get moved to 32 bit inodes. At that point, we could
probably pull the xfs_reno patch into xfsprogs and ship it....


Dave Chinner

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