From: Omar Sandoval <osandov@osandov.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: linux-xfs@vger.kernel.org, Eric Sandeen <sandeen@redhat.com>
Subject: Re: xfsdump confused by ino's < root ino
Date: Wed, 15 May 2019 13:53:14 -0700 [thread overview]
Message-ID: <20190515205314.GA4599@vader> (raw)
In-Reply-To: <f37ae69d-39a6-b2d0-1cc9-806d1d597086@sandeen.net>
On Wed, May 15, 2019 at 03:51:07PM -0500, Eric Sandeen wrote:
> On 5/15/19 3:47 PM, Omar Sandoval wrote:
> > Hi,
> >
> > We use xfsdump and xfsrestore (v3.1.7) to back up one of our storage
> > systems, and we ran into an issue where xfsdump prints the following for
> > a mount which isn't a bind mount:
> >
> > /sbin/xfsdump: NOTE: root ino 136 differs from mount dir ino 256, bind mount?
> >
> > Which also results in a crash from xfsrestore:
> >
> > xfsrestore: tree.c:757: tree_begindir: Assertion `ino != persp->p_rootino || hardh == persp->p_rooth' failed.
> >
> > Looking at [1], xfsdump uses bulkstat to get the minimum inode number on
> > the filesystem. But, at least one of our filesystems has a root inode
> > number of 256 and uses inode numbers 136-199, which tricks xfsdump into
> > thinking that the filesystem is bind mounted. Is this an invalid
> > assumption in xfsdump, or is it filesystem corruption?
> >
> > Thanks!
> >
> > 1: https://git.kernel.org/pub/scm/fs/xfs/xfsdump-dev.git/commit/?id=25195ebf107dc81b1b7cea1476764950e1d6cc9d
>
> Yep, this is that heuristic going wrong. We (I) didn't realize that we could ever
> get inode numbers allocated which were less than the root inode, but alas.
>
> It's an invalid assumption in xfsdump. I guess we need to find a way
> out of this ... the goal was to detect bind mounts, but apparently
> the situation you have is more common than expected (well, we expected
> it to not exist ...)
>
> For now just using an older version of xfsdump should be a workaround,
> sorry about that.
>
> -Eric
Great, thanks for the confirmation!
prev parent reply other threads:[~2019-05-15 20:53 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-15 20:47 xfsdump confused by ino's < root ino Omar Sandoval
2019-05-15 20:51 ` Eric Sandeen
2019-05-15 20:53 ` Omar Sandoval [this message]
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=20190515205314.GA4599@vader \
--to=osandov@osandov.com \
--cc=linux-xfs@vger.kernel.org \
--cc=sandeen@redhat.com \
--cc=sandeen@sandeen.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.