On 10/19/21 3:44 PM, Dave Chinner wrote:
On Tue, Oct 19, 2021 at 10:18:31AM -0500, Eric Sandeen wrote:
Darrick taught xfs_admin to upgrade filesystems to bigtime and inobtcount, which is
nice! But it operates via xfs_repair on an unmounted filesystem, so it's a bit tricky
to do for the root fs.
It occurs to me that with the /forcefsck and /fsckoptions files[1], we might be able
to make this a bit easier. i.e. touch /forcefsck and add "-c bigtime=1" to /fsckoptions,
and then the initrd/initramfs should run xfs_repair with -c bigtime=1 and do the upgrade.
Does that happen before/after swap is enabled?
Good question, and I don't know.
What problems can arise from a failed repair here?
In general, we've always said that an aborted repair should leave things
in a not-worse state, I think? As in "repair is safe to cancel?"
I don't know if that holds true on an upgrade path though...
Also, ISTR historical problems with doing initrd based root fs
operations because it's not uncommon for the root filesystem to fail
to cleanly unmount on shutdown. i.e. it can end up not having the
unmount record written because shutdown finishes with the superblock
still referenced. Hence the filesystem has to be mounted and the log
replayed before repair can be run on it....
However ... fsck.xfs doesn't accept that option, and doesn't pass
it on to repair, so that doesn't work.
It seems reasonable to me for fsck.xfs, when it gets the "-f"
option via init, and the special handling we do already to
actually Do Something(tm)[2], we could then also pass on any
additional options we got via the /fsckoptions method.
Does anyone see a problem with this? If not, would anyone like to
take this on as a small project?
As long as it doesn't result in an unbootable system on failure, it
sounds like a good idea to me.
The /forcefsck is already honored, so I think the only additional possible
pitfalls would be specifically related to the upgrade path.
But, that upgrade path would encourage more people to make use of it, so...
I guess in general, if we honor forcefsck and translate that into a real
xfs_repair run, it probably makes sense to honor command line options in
general.
-Eric
