summaryrefslogtreecommitdiffstats
path: root/fs/xfs/scrub/common.c
diff options
context:
space:
mode:
authorDave Chinner <dchinner@redhat.com>2024-03-19 11:29:03 +1100
committerChandan Babu R <chandanbabu@kernel.org>2024-03-25 10:17:18 +0530
commit15922f5dbf51dad334cde888ce6835d377678dc9 (patch)
treee080e601f762891ff99724bda2119ec903cb7bdd /fs/xfs/scrub/common.c
parent4cece764965020c22cff7665b18a012006359095 (diff)
downloadlinux-stable-15922f5dbf51dad334cde888ce6835d377678dc9.tar.gz
linux-stable-15922f5dbf51dad334cde888ce6835d377678dc9.tar.bz2
linux-stable-15922f5dbf51dad334cde888ce6835d377678dc9.zip
xfs: allow sunit mount option to repair bad primary sb stripe values
If a filesystem has a busted stripe alignment configuration on disk (e.g. because broken RAID firmware told mkfs that swidth was smaller than sunit), then the filesystem will refuse to mount due to the stripe validation failing. This failure is triggering during distro upgrades from old kernels lacking this check to newer kernels with this check, and currently the only way to fix it is with offline xfs_db surgery. This runtime validity checking occurs when we read the superblock for the first time and causes the mount to fail immediately. This prevents the rewrite of stripe unit/width via mount options that occurs later in the mount process. Hence there is no way to recover this situation without resorting to offline xfs_db rewrite of the values. However, we parse the mount options long before we read the superblock, and we know if the mount has been asked to re-write the stripe alignment configuration when we are reading the superblock and verifying it for the first time. Hence we can conditionally ignore stripe verification failures if the mount options specified will correct the issue. We validate that the new stripe unit/width are valid before we overwrite the superblock values, so we can ignore the invalid config at verification and fail the mount later if the new values are not valid. This, at least, gives users the chance of correcting the issue after a kernel upgrade without having to resort to xfs-db hacks. Signed-off-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: "Darrick J. Wong" <djwong@kernel.org> Signed-off-by: Chandan Babu R <chandanbabu@kernel.org>
Diffstat (limited to 'fs/xfs/scrub/common.c')
0 files changed, 0 insertions, 0 deletions