Re: [PATCH RFC] btrfs: Use backup superblocks if and only if the first superblock is valid but corrupted.

[Austin S Hemmelgarn <ahferroin7@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2253 bytes --]

On 07/27/2014 08:29 PM, Qu Wenruo wrote:
> 
> -------- 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@gmail.com>
> To: Chris Mason <clm@fb.com>, Qu Wenruo <quwenruo@cn.fujitsu.com>,
> <linux-btrfs@vger.kernel.org>
> 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?
Personally, I'd add a new mount option, but make recovery imply that option.



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2967 bytes --]