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
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
