]> git.ipfire.org Git - thirdparty/xfsprogs-dev.git/commit - repair/globals.h
repair: copy, don't clear, stripe geometry in backup SB
authorEric Sandeen <sandeen@redhat.com>
Wed, 16 Jul 2014 03:52:47 +0000 (13:52 +1000)
committerDave Chinner <david@fromorbit.com>
Wed, 16 Jul 2014 03:52:47 +0000 (13:52 +1000)
commit6bf4721d47d9755029a7ec944af2832bd115a851
treec005485e9d112289efca466be2c58dc6bc311400
parentb6ad8545923aaa0bcc6ec7f7d3edea00382ef3a1
repair: copy, don't clear, stripe geometry in backup SB

Today, if we have a filesystem with stripe geometry and
a damaged primary superblock, we will zero out stripe geometry
if we have copied the backup.

I'm guessing this might be because changing geometry with mount
options only updates the primary, so backups aren't guaranteed
to be current or correct.

Unfortunately, that leaves us with sb 0 w/ no geom, and backups
*with* geom, so the next repair finds the mismatch, and complains.
(In other words, the 2nd repair does not come up clean.)_
And ... the second repair copies the backup stripe geometry back
into the primary!

Rather than clearing stripe geometry in this case, just leave it
at what was found in the backup super, and inform the user that this
was done.  This leaves a consistent filesystem, and gives the user
a heads-up to double-check the result.

This can all be demonstrated and tested by running xfs/030 with
geometry set in MKFS_OPTIONS.  (To really make the test pass,
we need to filter the warning out of repair output.)

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
repair/globals.h
repair/sb.c
repair/xfs_repair.c