Re: [PATCH 5/5] btrfs: Greatly simplify btrfs_read_dev_super

[Anand Jain <anand.jain@oracle.com>]

On 12/07/2017 11:07 PM, Anand Jain wrote:
> 
> 
> On 12/07/2017 12:24 AM, David Sterba wrote:
>> On Mon, Dec 04, 2017 at 06:20:09PM +0200, Nikolay Borisov wrote:
>>>>> I don't understand what problem *should* be solved here...
>>>>
>>>> Without any further checks and validation, we cannot simply iterate 
>>>> over
>>>> all superblocks and try to mount anything that looks ok. Even if the
>>>> offsets exist on the block device.  The fsid should be at least 
>>>> checked,
>>>> but that's still not enough to ensure the 1st copy is what we want to
>>>> mount.
>>>
>>> I'm more inclined to agree with Anand here, that if the users wants to
>>> mount with -t btrfs then the filesystem should assume it's correct to
>>> use any of the additional superblocks.
>>
>> If and only if the additional superblocks are valid. And if we can't
>> read the primary superblock, we don't have enough information to
>> establish the validation.  EIO?  We don't have anything.  CRC mismatch?
>> Can't trust the whole data.  We need FSID and total_size at least. Other
>> actions are limited from inside kernel.

  ext4 has mount option -o sb=<copy_num> to specify the copy num to use.

  Not sure if I have dug enough but as of now I don't find any pitfall.
  Only funny thing is you can mount a device even after wipefs -a and
  recover its primary SB, to which my view is that the problem is at
  the wipefs -a end, not able to wipe all SB copies.

  I sent out an experimental RFC patch here:
    [PATCH RFC] btrfs: self heal from SB fail

  Pls try out, any problem that you could think off by this approach.

Thanks, Anand