From: Gao Xiang <hsiangkao@redhat.com>
To: linux-xfs@vger.kernel.org
Cc: Eric Sandeen <sandeen@sandeen.net>, Donald Douwsma <ddouwsma@redhat.com>
Subject: Re: [RFC PATCH v2] xfsrestore: fix rootdir due to xfsdump bulkstat misuse
Date: Mon, 16 Nov 2020 16:13:59 +0800 [thread overview]
Message-ID: <20201116081359.GA1486562@xiangao.remote.csb> (raw)
In-Reply-To: <20201116080723.1486270-1-hsiangkao@redhat.com>
On Mon, Nov 16, 2020 at 04:07:23PM +0800, Gao Xiang wrote:
> If rootino is wrong and misspecified to a subdir inode #,
> the following assertion could be triggered:
> assert(ino != persp->p_rootino || hardh == persp->p_rooth);
>
> This patch adds a '-x' option (another awkward thing is that
> the codebase doesn't support long options) to address
> problamatic images by searching for the real dir, the reason
> that I don't enable it by default is that I'm not very confident
> with the xfsrestore codebase and xfsdump bulkstat issue will
> also be fixed immediately as well, so this function might be
> optional and only useful for pre-exist corrupted dumps.
>
> In details, my understanding of the original logic is
> 1) xfsrestore will create a rootdir node_t (p_rooth);
> 2) it will build the tree hierarchy from inomap and adopt
> the parent if needed (so inodes whose parent ino hasn't
> detected will be in the orphan dir, p_orphh);
> 3) during this period, if ino == rootino and
> hardh != persp->p_rooth (IOWs, another node_t with
> the same ino # is created), that'd be definitely wrong.
>
> So the proposal fix is that
> - considering the xfsdump root ino # is a subdir inode, it'll
> trigger ino == rootino && hardh != persp->p_rooth condition;
> - so we log this node_t as persp->p_rooth rather than the
> initial rootdir node_t created in 1);
> - we also know that this node is actually a subdir, and after
> the whole inomap is scanned (IOWs, the tree is built),
> the real root dir will have the orphan dir parent p_orphh;
> - therefore, we walk up by the parent until some node_t has
> the p_orphh, so that's it.
>
> Cc: Donald Douwsma <ddouwsma@redhat.com>
> Signed-off-by: Gao Xiang <hsiangkao@redhat.com>
> ---
> changes since RFC v1:
> - fix non-dir fake rootino cases since tree_begindir()
> won't be triggered for these non-dir, and we could do
> that in tree_addent() instead (fault injection verified);
>
> - fix fake rootino case with gen = 0 as well, for more
> details, see the inlined comment in link_hardh()
> (fault injection verified as well).
>
> Anyway, all of this behaves like a workaround and I have
> no idea how to deal it more gracefully.
>
My manual fault injection patch:
- inject a non-dir fake rootino;
- inject all inode gen = 0 (to check the fake rootino case with gen = 0);
- disable the fake rootino case with gen = 0 workaround, and see
xfsrestore: tree.c:1003: tree_addent: Assertion `hardp->n_nrh != NRH_NULL' failed.
could happen.
diff --git a/dump/content.c b/dump/content.c
index c11d9b4..2d27d24 100644
--- a/dump/content.c
+++ b/dump/content.c
@@ -1509,6 +1509,7 @@ baseuuidbypass:
}
scwhdrtemplatep->cih_rootino = sc_rootxfsstatp->bs_ino;
+ scwhdrtemplatep->cih_rootino = 25166002; /* inject some real non-dir ino # */
inomap_writehdr(scwhdrtemplatep);
/* log the dump size. just a rough approx.
diff --git a/restore/content.c b/restore/content.c
index e807a83..f493fdb 100644
--- a/restore/content.c
+++ b/restore/content.c
@@ -8143,7 +8143,7 @@ read_filehdr(drive_t *drivep, filehdr_t *fhdrp, bool_t fhcs)
return RV_CORRUPT;
}
}
-
+ bstatp->bs_gen = 0;
return RV_OK;
}
@@ -8277,6 +8277,8 @@ read_dirent(drive_t *drivep,
}
}
+ dhdrp->dh_gen = 0;
+
mlog(MLOG_NITTY,
"read dirent hdr ino %llu gen %u size %u\n",
dhdrp->dh_ino,
diff --git a/restore/tree.c b/restore/tree.c
index 918fa01..2d8dec5 100644
--- a/restore/tree.c
+++ b/restore/tree.c
@@ -3886,6 +3886,7 @@ link_hardh(xfs_ino_t ino, gen_t gen)
{
nh_t tmp = hash_find(ino, gen);
+#if 0
/*
* XXX (another workaround): the simply way is that don't reuse node_t
* with gen = 0 created in tree_init(). Otherwise, it could cause
@@ -3903,6 +3904,7 @@ _("link out fake rootino %llu with gen=0 created in tree_init()\n"), ino);
orig_rooth = tmp;
return NH_NULL;
}
+#endif
return tmp;
}
--
2.18.4
next prev parent reply other threads:[~2020-11-16 8:27 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-13 12:51 [RFC PATCH] xfsrestore: fix rootdir due to xfsdump bulkstat misuse Gao Xiang
2020-11-13 14:10 ` Eric Sandeen
2020-11-13 14:15 ` Gao Xiang
2020-11-16 8:23 ` Gao Xiang
2020-11-16 8:07 ` [RFC PATCH v2] " Gao Xiang
2020-11-16 8:13 ` Gao Xiang [this message]
2021-09-27 15:00 ` Bill O'Donnell
2021-12-20 15:14 ` Masayoshi Mizuma
2022-06-10 23:05 ` Hironori Shiina
2022-06-30 19:19 ` Hironori Shiina
2022-09-28 19:10 ` [RFC PATCH V3] " Hironori Shiina
2022-09-29 18:17 ` Darrick J. Wong
2023-04-19 14:16 ` Eric Sandeen
2023-04-19 15:40 ` Darrick J. Wong
2023-04-21 9:10 ` Carlos Maiolino
2023-04-21 16:14 ` Darrick J. Wong
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=20201116081359.GA1486562@xiangao.remote.csb \
--to=hsiangkao@redhat.com \
--cc=ddouwsma@redhat.com \
--cc=linux-xfs@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).