On Fri, Dec 22, 2017 at 04:43:02PM -0800, Darrick J. Wong wrote:
> From: Darrick J. Wong <darrick.wong@xxxxxxxxxx>
>
> The superblock validation routines return a variety of error codes to
> reject a mount request. For scrub we can assume that the mount
> succeeded, so if we see these things appear when scrubbing secondary sb
> X, we can treat them all like corruption.
>
> Signed-off-by: Darrick J. Wong <darrick.wong@xxxxxxxxxx>
> ---
> fs/xfs/scrub/agheader.c | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
>
> diff --git a/fs/xfs/scrub/agheader.c b/fs/xfs/scrub/agheader.c
> index b599358..97beb47 100644
> --- a/fs/xfs/scrub/agheader.c
> +++ b/fs/xfs/scrub/agheader.c
> @@ -126,6 +126,22 @@ xfs_scrub_superblock(
> error = xfs_trans_read_buf(mp, sc->tp, mp->m_ddev_targp,
> XFS_AGB_TO_DADDR(mp, agno, XFS_SB_BLOCK(mp)),
> XFS_FSS_TO_BB(mp, 1), 0, &bp, &xfs_sb_buf_ops);
> + /*
> + * The superblock verifier can return several different error codes
> + * if it thinks the superblock doesn't look right. For a mount these
> + * would all get bounced back to userspace, but if we're here then the
> + * fs mounted successfully, which means that this secondary superblock
> + * is simply incorrect. Treat all these codes the same way we treat
> + * any corruption.
> + */
> + switch (error) {
> + case -EINVAL: /* also -EWRONGFS */
> + case -ENOSYS:
> + case -EFBIG:
> + error = -EFSCORRUPTED;
> + default:
> + break;
> + }
> if (!xfs_scrub_process_error(sc, agno, XFS_SB_BLOCK(mp), &error))
> return error;
Yes, this change looks fine, so
Reviewed-by: Dave Chinner <dchinner@xxxxxxxxxx>
However, what I just realised is that the in-memory primary
superblock buffer that we do all our normal modification/logging
work on is an uncached buffer that accessed through xfs_getsb(), not
a cached buffer we access through xfs_trans_read_buf().
Does the scrub code take this into account?
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
