From: Eric Sandeen <sandeen@sandeen.net>
To: "Darrick J. Wong" <darrick.wong@oracle.com>, bfoster@redhat.com
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH v2 5/9] xfs_db: add inobtcnt upgrade path
Date: Wed, 18 Nov 2020 15:05:42 -0600 [thread overview]
Message-ID: <cd58a995-7146-abfc-f24e-76b57067cebb@sandeen.net> (raw)
In-Reply-To: <20201116211351.GT9695@magnolia>
On 11/16/20 3:13 PM, Darrick J. Wong wrote:
> From: Darrick J. Wong <darrick.wong@oracle.com>
>
> Enable users to upgrade their filesystems to support inode btree block
> counters.
>
> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> ---
> v2: set inprogress to force repair (which xfs_admin immediately does),
> clean up the code to pass around fewer arguments, and try to revert the
> change if we hit io errors
> ---
sooooo the inprogress thing sets off some unexpected behavior.
In testing this, I noticed that if we have inprogress set, and uknown features/
version on disk, we go looking for backup superblocks and actually end up
corrupting the filesystem before bailing out:
# xfs_repair /dev/pmem0p2
Phase 1 - find and verify superblock...
bad primary superblock - filesystem mkfs-in-progress bit set !!!
attempting to find secondary superblock...
.found candidate secondary superblock...
verified secondary superblock...
writing modified primary superblock
sb realtime bitmap inode value 18446744073709551615 (NULLFSINO) inconsistent with calculated value 129
resetting superblock realtime bitmap inode pointer to 129
sb realtime summary inode value 18446744073709551615 (NULLFSINO) inconsistent with calculated value 130
resetting superblock realtime summary inode pointer to 130
Superblock has unknown compat/rocompat/incompat features (0x0/0x8/0x0).
Using a more recent xfs_repair is recommended.
Found unsupported filesystem features. Exiting now.
# xfs_db -c check /dev/pmem0p2
disconnected inode 129, nlink 1
disconnected inode 130, nlink 1
so this seems to have exposed a hole in how repair deals with unknown features
when the inprogress bit is set.
And TBH scampering off to find backup superblocks to "repair" an inprogress
filesystem seems like ... not the right thing to do after a feature upgrade.
I'm not sure what's better, but
> bad primary superblock - filesystem mkfs-in-progress bit set !!!
seems ... unexpected for this purpose.
-Eric
next prev parent reply other threads:[~2020-11-18 21:06 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-26 23:33 [PATCH v4 0/9] xfsprogs: add a inode btree blocks counts to the AGI header Darrick J. Wong
2020-10-26 23:33 ` [PATCH 1/9] xfs: store inode btree block counts in " Darrick J. Wong
2020-10-26 23:33 ` [PATCH 2/9] xfs: use the finobt block counts to speed up mount times Darrick J. Wong
2020-10-26 23:33 ` [PATCH 3/9] xfs: support inode btree blockcounts in online repair Darrick J. Wong
2020-10-26 23:33 ` [PATCH 4/9] xfs_db: support displaying inode btree block counts in AGI header Darrick J. Wong
2020-10-28 17:28 ` Brian Foster
2020-10-26 23:33 ` [PATCH 5/9] xfs_db: add inobtcnt upgrade path Darrick J. Wong
2020-10-28 17:29 ` Brian Foster
2020-10-29 0:03 ` Darrick J. Wong
2020-10-29 12:09 ` Brian Foster
2020-10-29 15:42 ` Darrick J. Wong
2020-11-16 21:13 ` [PATCH v2 " Darrick J. Wong
2020-11-18 21:05 ` Eric Sandeen [this message]
2020-11-20 1:05 ` Darrick J. Wong
2020-11-20 4:10 ` Eric Sandeen
2020-10-26 23:33 ` [PATCH 6/9] xfs_repair: check inode btree block counters in AGI Darrick J. Wong
2020-10-28 17:29 ` Brian Foster
2020-10-29 1:01 ` Darrick J. Wong
2020-11-16 17:19 ` [PATCH v2 " Darrick J. Wong
2020-11-16 20:29 ` Eric Sandeen
2020-10-26 23:33 ` [PATCH 7/9] xfs_repair: regenerate " Darrick J. Wong
2020-10-28 17:30 ` Brian Foster
2020-10-26 23:33 ` [PATCH 8/9] mkfs: enable the inode btree counter feature Darrick J. Wong
2020-10-28 17:30 ` Brian Foster
2020-10-29 1:02 ` Darrick J. Wong
2020-10-26 23:34 ` [PATCH 9/9] xfs: enable new inode btree counters feature 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=cd58a995-7146-abfc-f24e-76b57067cebb@sandeen.net \
--to=sandeen@sandeen.net \
--cc=bfoster@redhat.com \
--cc=darrick.wong@oracle.com \
--cc=linux-xfs@vger.kernel.org \
/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.