From: Hans-Peter Jansen <hpj@urpla.net>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com
Subject: Re: strange behavior of a larger xfs directory
Date: Wed, 06 Mar 2013 00:48:25 +0100 [thread overview]
Message-ID: <1517139.CltWl8VXzZ@xrated> (raw)
In-Reply-To: <20130305222941.GP26081@dastard>
[-- Attachment #1: Type: text/plain, Size: 3582 bytes --]
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:
> > 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....
Ahh, I see. These interfaces cannot be exercised much, given that google
didn't relate them to libattr prominently..
> .....
>
> > +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
> $
Done that up to this point ;-) Nice and easy.
Committed, attached, and public build is on the way.
Dave, you made my day, ahem, night. Thank you very much.
To a casual consumer of this thread: go, grab the xfs_reno.patch in the
preceding mail, and the attached patch, apply both to a current version of
xfsprogs, build, and read man xfs_reno. Seriously.
> 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....
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?
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..
Cheers,
Pete
[-- Attachment #2: xfs_reno_fix.diff --]
[-- Type: text/x-patch, Size: 3908 bytes --]
Index: b/configure.ac
===================================================================
--- a/configure.ac
+++ b/configure.ac
@@ -101,6 +101,10 @@ AC_PACKAGE_NEED_UUIDCOMPARE
AC_PACKAGE_NEED_PTHREAD_H
AC_PACKAGE_NEED_PTHREADMUTEXINIT
+AC_PACKAGE_NEED_ATTRIBUTES_H
+AC_PACKAGE_NEED_ATTRIBUTES_MACROS
+AC_PACKAGE_NEED_ATTRGET_LIBATTR
+
AC_HAVE_FADVISE
AC_HAVE_MADVISE
AC_HAVE_MINCORE
Index: b/include/builddefs.in
===================================================================
--- a/include/builddefs.in
+++ b/include/builddefs.in
@@ -34,6 +34,7 @@ LIBTERMCAP = @libtermcap@
LIBEDITLINE = @libeditline@
LIBREADLINE = @libreadline@
LIBBLKID = @libblkid@
+LIBATTR = @libattr@
LIBXFS = $(TOPDIR)/libxfs/libxfs.la
LIBXCMD = $(TOPDIR)/libxcmd/libxcmd.la
LIBXLOG = $(TOPDIR)/libxlog/libxlog.la
Index: b/m4/package_attrdev.m4
===================================================================
--- /dev/null
+++ b/m4/package_attrdev.m4
@@ -0,0 +1,79 @@
+AC_DEFUN([AC_PACKAGE_NEED_ATTR_XATTR_H],
+ [ AC_CHECK_HEADERS([attr/xattr.h])
+ if test "$ac_cv_header_attr_xattr_h" != "yes"; then
+ echo
+ echo 'FATAL ERROR: attr/xattr.h does not exist.'
+ echo 'Install the extended attributes (attr) development package.'
+ echo 'Alternatively, run "make install-dev" from the attr source.'
+ exit 1
+ fi
+ ])
+
+AC_DEFUN([AC_PACKAGE_NEED_ATTR_ERROR_H],
+ [ AC_CHECK_HEADERS([attr/error_context.h])
+ if test "$ac_cv_header_attr_error_context_h" != "yes"; then
+ echo
+ echo 'FATAL ERROR: attr/error_context.h does not exist.'
+ echo 'Install the extended attributes (attr) development package.'
+ echo 'Alternatively, run "make install-dev" from the attr source.'
+ exit 1
+ fi
+ ])
+
+AC_DEFUN([AC_PACKAGE_NEED_ATTRIBUTES_H],
+ [ have_attributes_h=false
+ AC_CHECK_HEADERS([attr/attributes.h sys/attributes.h], [have_attributes_h=true], )
+ if test "$have_attributes_h" = "false"; then
+ echo
+ echo 'FATAL ERROR: attributes.h does not exist.'
+ echo 'Install the extended attributes (attr) development package.'
+ echo 'Alternatively, run "make install-dev" from the attr source.'
+ exit 1
+ fi
+ ])
+
+AC_DEFUN([AC_PACKAGE_WANT_ATTRLIST_LIBATTR],
+ [ AC_CHECK_LIB(attr, attr_list, [have_attr_list=true], [have_attr_list=false])
+ AC_SUBST(have_attr_list)
+ ])
+
+AC_DEFUN([AC_PACKAGE_NEED_GETXATTR_LIBATTR],
+ [ AC_CHECK_LIB(attr, getxattr,, [
+ echo
+ echo 'FATAL ERROR: could not find a valid Extended Attributes library.'
+ echo 'Install the extended attributes (attr) development package.'
+ echo 'Alternatively, run "make install-lib" from the attr source.'
+ exit 1
+ ])
+ libattr="-lattr"
+ test -f ${libexecdir}${libdirsuffix}/libattr.la && \
+ libattr="${libexecdir}${libdirsuffix}/libattr.la"
+ AC_SUBST(libattr)
+ ])
+
+AC_DEFUN([AC_PACKAGE_NEED_ATTRGET_LIBATTR],
+ [ AC_CHECK_LIB(attr, attr_get,, [
+ echo
+ echo 'FATAL ERROR: could not find a valid Extended Attributes library.'
+ echo 'Install the extended attributes (attr) development package.'
+ echo 'Alternatively, run "make install-lib" from the attr source.'
+ exit 1
+ ])
+ libattr="-lattr"
+ test -f ${libexecdir}${libdirsuffix}/libattr.la && \
+ libattr="${libexecdir}${libdirsuffix}/libattr.la"
+ AC_SUBST(libattr)
+ ])
+
+AC_DEFUN([AC_PACKAGE_NEED_ATTRIBUTES_MACROS],
+ [ AC_MSG_CHECKING([macros in attr/attributes.h])
+ AC_TRY_LINK([
+#include <sys/types.h>
+#include <attr/attributes.h>],
+ [ int x = ATTR_SECURE; ], [ echo ok ], [
+ echo
+ echo 'FATAL ERROR: could not find a current attributes header.'
+ echo 'Upgrade the extended attributes (attr) development package.'
+ echo 'Alternatively, run "make install-dev" from the attr source.'
+ exit 1 ])
+ ])
[-- Attachment #3: Type: text/plain, Size: 121 bytes --]
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-03-05 23:48 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
2013-03-05 23:48 ` Hans-Peter Jansen [this message]
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=1517139.CltWl8VXzZ@xrated \
--to=hpj@urpla.net \
--cc=david@fromorbit.com \
--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