[lvc-project] [PATCH v2] xfs: do not inactivate inodes on a failed mount

[Christoph Hellwig]

On Tue, Jun 02, 2026 at 05:37:17PM +0300, Mikhail Lobanov wrote:
> XFS already encodes this rule: xfs_inode_needs_inactive() returns false
> when the mount is shut down ("If the log isn't running, push inodes
> straight to reclaim"), so an inode destroyed on a shut down mount is
> never queued for inactivation.  The gap is that this is only evaluated at
> queue time; an inode queued while the mount was still live is then
> inactivated by the worker even after the mount has been torn down.  Honour
> the same invariant at gc time: in xfs_inodegc_inactivate(), skip
> xfs_inactive() when the mount is shut down and just make the inode
> reclaimable (xfs_inodegc_set_reclaimable() already handles the shutdown
> case).  This is not a new policy, just consistency with the existing one.
> 
> Then, in the xfs_mountfs() failure path, shut the mount down before
> flushing the inodegc queue, so the queued inodes are dropped to reclaim
> instead of inactivated.

Doing a shutdown on failed mount is actually a really nice idea!  I
hadn't though of that before, but it makes a lot of sense.

> Note that shutting down alone is not enough to stop the crash:
> xfs_inactive() calls xfs_qm_dqattach() before any shutdown-sensitive
> transaction, and neither xfs_qm_need_dqattach() nor xfs_qm_dqattach()
> tests for shutdown - so the worker change is what actually closes it.

The Sashiko review points out a that skipping the entire inactive can
leak the dquot references when we get here due to a normal shutdown,
and I think it is right so we migþt still need to call into the quota
code in an else branch that checks if quotas actually were attached
and drop the reference very carefully.  It probably makes sense to
split all these shutdown in inactive handling into a separate prep
patch from shutting down in the mount failure path as well.

> Open question: in the failure path I used xfs_force_shutdown(mp,
> SHUTDOWN_FORCE_UMOUNT) to mark the fs down.  It logs "User initiated
> shutdown received", which is a bit misleading for a mount failure (the tag
> actually shown is "Metadata I/O Error (0x4)").  Would a different flag, or
> just quietly setting the shutdown state, be preferable here?

I think a different state makes sense.  It could be quite as we usually
have other messages for mount failures, but I dont think a message
really hurts either, so in doubt avoid the special casing.

> +	 * If the filesystem has been shut down - for example a mount that failed

Overly long line here.

> +	 * to reclaim instead of being inactivated: a failed mount must not write

.. and here