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: Wed, 6 Mar 2013 09:29:41 +1100 [thread overview]
Message-ID: <20130305222941.GP26081@dastard> (raw)
In-Reply-To: <8026381.3dEJ1E4pzL@xrated>
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
> +LLDLIBS = $(LIBATTR)
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:
+LLDLIBS = $(LIBATTR)
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
configure.ac
include/builddefs.in
m4/package_attrdev.m4
$
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....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-03-05 22:30 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
2013-03-04 23:05 ` Dave Chinner
2013-03-05 20:32 ` Hans-Peter Jansen
2013-03-05 22:29 ` Dave Chinner [this message]
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=20130305222941.GP26081@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox