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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




-------- 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@xxxxxxxxx>
To: Chris Mason <clm@xxxxxx>, Qu Wenruo <quwenruo@xxxxxxxxxxxxxx>, <linux-btrfs@xxxxxxxxxxxxxxx>
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?

Thanks,
Qu
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux