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.
smime.p7s
Description: S/MIME Cryptographic Signature
