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. > Otherwise we should explicitly > state somewhere that the superblock copies are there only for the sake > of the user-space tools, in which case this patch can go in, albeit with > some rewording. Unless there's something I'm missing to address the concerns above, I'm for (an updated version) of your patch. -- 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
