linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Brian Foster <bfoster@redhat.com>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: sandeen@sandeen.net, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 2/3] xfs: define a new "needrepair" feature
Date: Tue, 1 Dec 2020 11:18:12 -0500	[thread overview]
Message-ID: <20201201161812.GD1205666@bfoster> (raw)
In-Reply-To: <160679385127.447856.3129099457617444604.stgit@magnolia>

On Mon, Nov 30, 2020 at 07:37:31PM -0800, Darrick J. Wong wrote:
> From: Darrick J. Wong <darrick.wong@oracle.com>
> 
> Define an incompat feature flag to indicate that the filesystem needs to
> be repaired.  While libxfs will recognize this feature, the kernel will
> refuse to mount if the feature flag is set, and only xfs_repair will be
> able to clear the flag.  The goal here is to force the admin to run
> xfs_repair to completion after upgrading the filesystem, or if we
> otherwise detect anomalies.
> 
> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> ---

IIUC, we're using an incompat bit to intentionally ensure the filesystem
cannot mount, even on kernels that predate this particular "needs
repair" feature. The only difference is that an older kernel would
complain about an unknown feature and return a different error code.
Right?

That seems reasonable, but out of curiousity is there a need/reason for
using an incompat bit over an ro_compat bit?

Brian

>  fs/xfs/libxfs/xfs_format.h |    7 +++++++
>  fs/xfs/xfs_mount.c         |    6 ++++++
>  2 files changed, 13 insertions(+)
> 
> 
> diff --git a/fs/xfs/libxfs/xfs_format.h b/fs/xfs/libxfs/xfs_format.h
> index dd764da08f6f..5d8ba609ac0b 100644
> --- a/fs/xfs/libxfs/xfs_format.h
> +++ b/fs/xfs/libxfs/xfs_format.h
> @@ -468,6 +468,7 @@ xfs_sb_has_ro_compat_feature(
>  #define XFS_SB_FEAT_INCOMPAT_SPINODES	(1 << 1)	/* sparse inode chunks */
>  #define XFS_SB_FEAT_INCOMPAT_META_UUID	(1 << 2)	/* metadata UUID */
>  #define XFS_SB_FEAT_INCOMPAT_BIGTIME	(1 << 3)	/* large timestamps */
> +#define XFS_SB_FEAT_INCOMPAT_NEEDSREPAIR (1 << 4)	/* needs xfs_repair */
>  #define XFS_SB_FEAT_INCOMPAT_ALL \
>  		(XFS_SB_FEAT_INCOMPAT_FTYPE|	\
>  		 XFS_SB_FEAT_INCOMPAT_SPINODES|	\
> @@ -584,6 +585,12 @@ static inline bool xfs_sb_version_hasinobtcounts(struct xfs_sb *sbp)
>  		(sbp->sb_features_ro_compat & XFS_SB_FEAT_RO_COMPAT_INOBTCNT);
>  }
>  
> +static inline bool xfs_sb_version_needsrepair(struct xfs_sb *sbp)
> +{
> +	return XFS_SB_VERSION_NUM(sbp) == XFS_SB_VERSION_5 &&
> +		(sbp->sb_features_incompat & XFS_SB_FEAT_INCOMPAT_NEEDSREPAIR);
> +}
> +
>  /*
>   * end of superblock version macros
>   */
> diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c
> index 7bc7901d648d..2853ad49b27d 100644
> --- a/fs/xfs/xfs_mount.c
> +++ b/fs/xfs/xfs_mount.c
> @@ -266,6 +266,12 @@ xfs_sb_validate_mount(
>  	struct xfs_buf		*bp,
>  	struct xfs_sb		*sbp)
>  {
> +	/* Filesystem claims it needs repair, so refuse the mount. */
> +	if (xfs_sb_version_needsrepair(&mp->m_sb)) {
> +		xfs_warn(mp, "Filesystem needs repair.  Please run xfs_repair.");
> +		return -EFSCORRUPTED;
> +	}
> +
>  	/*
>  	 * Don't touch the filesystem if a user tool thinks it owns the primary
>  	 * superblock.  mkfs doesn't clear the flag from secondary supers, so
> 


  reply	other threads:[~2020-12-01 16:19 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-01  3:37 [PATCH 0/3] xfs: add the ability to flag a fs for repair Darrick J. Wong
2020-12-01  3:37 ` [PATCH 1/3] xfs: move kernel-specific superblock validation out of libxfs Darrick J. Wong
2020-12-01 16:17   ` Brian Foster
2020-12-04 20:35   ` Eric Sandeen
2020-12-04 21:12     ` Darrick J. Wong
2020-12-04 21:46       ` Eric Sandeen
2020-12-04 23:02         ` Darrick J. Wong
2020-12-04 23:29         ` Dave Chinner
2020-12-01  3:37 ` [PATCH 2/3] xfs: define a new "needrepair" feature Darrick J. Wong
2020-12-01 16:18   ` Brian Foster [this message]
2020-12-01 16:25     ` Darrick J. Wong
2020-12-01 17:09       ` Brian Foster
2020-12-04 20:07     ` Eric Sandeen
2020-12-04 21:36       ` Darrick J. Wong
2020-12-01  3:37 ` [PATCH 3/3] xfs: enable the needsrepair feature Darrick J. Wong
2020-12-01 16:18   ` Brian Foster
2020-12-04 20:35   ` Eric Sandeen
2020-12-04  1:13 ` [PATCH 4/3] xfs_db: support the needsrepair feature flag in the version command Darrick J. Wong
2020-12-04 20:32   ` Eric Sandeen
2020-12-04 21:09     ` Darrick J. Wong
2020-12-04 21:16       ` Eric Sandeen
2020-12-04  1:13 ` [PATCH 5/3] xfs_repair: clear the needsrepair flag Darrick J. Wong
2020-12-06 23:09 [PATCH v2 0/3] xfs: add the ability to flag a fs for repair Darrick J. Wong
2020-12-06 23:09 ` [PATCH 2/3] xfs: define a new "needrepair" feature Darrick J. Wong
2020-12-06 23:47   ` Dave Chinner
2020-12-09 17:15   ` Eric Sandeen
2020-12-09 18:04   ` Christoph Hellwig
2020-12-09 18:10     ` Darrick J. Wong
2020-12-09 18:12       ` Christoph Hellwig

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=20201201161812.GD1205666@bfoster \
    --to=bfoster@redhat.com \
    --cc=darrick.wong@oracle.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).