public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Mario Bachmann <mbachman@stud.uni-frankfurt.de>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH] Re: xfsdump-3.0.4 problems
Date: Tue, 17 Aug 2010 17:47:31 +0200	[thread overview]
Message-ID: <20100817174731.0061f5ec@x2.grafnetz> (raw)
In-Reply-To: <20100817114550.GQ10429@dastard>

Am Tue, 17 Aug 2010 21:45:50 +1000
schrieb Dave Chinner <david@fromorbit.com>:

> On Tue, Aug 17, 2010 at 07:05:34PM +1000, Dave Chinner wrote:
> > On Tue, Aug 17, 2010 at 09:53:40AM +0200, Mario Bachmann wrote:
> > > Am Tue, 17 Aug 2010 17:13:37 +1000 > schrieb Dave Chinner <david@fromorbit.com>:
> > > > > Compiler: I use "gcc (Gentoo 4.4.4-r1 p1.0, pie-0.4.5) 4.4.4". 
> > > > > 
> > > > > Testing List (on one machine only):
> > > > > works:   x86_64, 2.6.34.4, xfsdump-3.0.1
> > > > > works:   x86_64, 2.6.34.4, xfsdump-3.0.4
> > > > > failure: x86_64, 2.6.35.2, xfsdump-3.0.1 (worked only one time)
> > > > > failure: x86_64, 2.6.35.2, xfsdump-3.0.4
> > > > 
> > > > Ok, that makes more sense - we changed the way bulkstat works in
> > > > from 2.6.34 to 2.6.35 to correctly validate inode numbers being
> > > > passed in via bulkstat, and hence files unlinked during the dump run
> > > > could return EINVAL when validating the directory structure (as they
> > > > no longer exist). Is you system completely idle while the dump
> > > > is running, or are files being removed while the dump is running?
> > > 
> > > I would call my system idle, when I use xfsdump. No rm or mv operations 
> > > are running while the dump. The first machine has a dual core 2.9 GHz and
> > > 8 GB of RAM and the filesystems are not really big (~10GB used). The second 
> > > machine has a dual core 2 GHz and 2 GB of RAM. 
> > 
> > Yup, I have reproduced it here. What is strange is that xfs_fsr uses
> > XFS_IOC_BULKSTAT_SINGLE, and that works fine on 2.6.35.2. The same
> > ioctl calls from xfsdump are failing, though, so something funny is
> > going on there.
> > 
> > I'll look into it further.
> 
> Ok, there is nothing wrong with the changes to the bulkstat code;
> when all the inodes in the filesystem are hot in the inode cache
> xfsdump succeeds.
> 
> When I run xfs_fsr per file to exercise the XFS_IOC_BULKSTAT_SINGLE
> path like so:
> 
> $ sudo find /mnt/test -type f -exec xfs_fsr -d -v {} \;
> 
> It succeeds without any bulkstat failures. A subsequent xfsdump
> invocation then succeeds without failure, either. Clearly the find
> is populating the inode cache for the subsequent bulkstat calls,
> 
> Ok, so the reason this wasn't picked up is that xfs_fsr silently
> ignores inodes that it gets an error from bulkstat on.
> 
> and it looks like
> Dropping caches then running xfsdump:
> 
> $ sudo sh -c "echo 3 > /proc/sys/vm/drop_caches"
> $ sudo xfsdump -l0 -L "Test" - /dev/vda 2> t.t |gzip - > ~/dump_test.gz
> 
> Results in failures.
> 
> /me sighs
> 
> My fault. I screwed up the btree lookup for the inode validation.
> Can you test the patch below?
> 
> Cheers,
> 
> Dave

Your patch works here with 2.6.35.2. 
:-)

Mario

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2010-08-17 15:47 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-16 16:22 xfsdump-3.0.4 problems Mario Bachmann
2010-08-16 22:30 ` Dave Chinner
2010-08-17  6:32   ` Mario Bachmann
2010-08-17  7:13     ` Dave Chinner
2010-08-17  7:53       ` Mario Bachmann
2010-08-17  9:05         ` Dave Chinner
2010-08-17 11:45           ` [PATCH] " Dave Chinner
2010-08-17 15:47             ` Mario Bachmann [this message]
2010-08-18 10:10             ` Christoph Hellwig
2010-08-27 11:18             ` Iustin Pop
2010-08-27 11:40               ` Dave Chinner
2010-09-24  9:53                 ` Mario Bachmann
2010-10-03  6:20                   ` Christoph Hellwig
2010-08-17  9:03       ` Christoph Hellwig

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=20100817174731.0061f5ec@x2.grafnetz \
    --to=mbachman@stud.uni-frankfurt.de \
    --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