-------- Original Message --------
Subject: Re: [PATCH RFC] btrfs: Use backup superblocks if and only if
the first superblock is valid but corrupted.
From: Austin S Hemmelgarn <ahferroin7@xxxxxxxxx>
To: Chris Mason <clm@xxxxxx>, Qu Wenruo <quwenruo@xxxxxxxxxxxxxx>,
<linux-btrfs@xxxxxxxxxxxxxxx>
Date: 2014年07月27日 10:57
On 07/24/2014 05:28 PM, Chris Mason wrote:
On 06/26/2014 11:53 PM, Qu Wenruo wrote:
Current btrfs will only use the first superblock, making the backup
superblocks only useful for 'btrfs rescue super' command.
The old problem is that if we use backup superblocks when the first
superblock is not valid, we will be able to mount a none btrfs
filesystem, which used to contains btrfs but other fs is made on it.
The old problem can be solved related easily by checking the first
superblock in a special way:
1) If the magic number in the first superblock does not match:
This filesystem is not btrfs anymore, just exit.
If end-user consider it's really btrfs, then old 'btrfs rescue super'
method is still available.
2) If the magic number in the first superblock matches but checksum does
not match:
This filesystem is btrfs but first superblock is corrupted, use
backup roots. Just continue searching remaining superblocks.
I do agree that in these cases we can trust that the backup superblock
comes from the same filesystem.
But, for right now I'd prefer the admin get involved in using the backup
supers. I think silently using the backups is going to lead to surprises.
Maybe there could be a mount non-default mount-option to use backup
superblocks iff the first one is corrupted, and then log a warning
whenever this actually happens? Not handling stuff like this
automatically really hurts HA use cases.
This seems better and comments also shows this idea.
What about merging the behavior into 'recovery' mount option or adding a
new mount option?
Thanks,
Qu
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html