xfs
[Top] [All Lists]

Re: [PATCH] xfs_repair: copy, don't clear, stripe geometry in backup SB

To: Eric Sandeen <sandeen@xxxxxxxxxx>
Subject: Re: [PATCH] xfs_repair: copy, don't clear, stripe geometry in backup SB
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Wed, 16 Jul 2014 12:58:10 +1000
Cc: xfs-oss <xfs@xxxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <53C06CE9.9000209@xxxxxxxxxx>
References: <53C06CE9.9000209@xxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Fri, Jul 11, 2014 at 06:02:01PM -0500, Eric Sandeen wrote:
> 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.)

There are a few other tests that also fail due to this. Can you
please send an updated filter patch to fstests@xxxxxxxxxxxxxxx?

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>