On Sun, Mar 10, 2019 at 7:18 PM Qu Wenruo <quwenruo.btrfs@xxxxxxx> wrote: > > > > On 2019/3/11 上午7:09, Chris Murphy wrote: > > In the case where superblock 0 at 65536 is valid but stale (older than > > the others): > > Then this means either the fs is fuzzed, or the FUA implementation of > the disk is completely screwed up. Fuzzed in this case by me. (Backstory: On linux-raid@ list, user accidentally zero'd first 1MiB of an mdadm array which contains Btrfs, but has a backup of this 1MiB. So I was testing in advance the behavior of restoring this 1MiB backup; but I'm guessing upon zero the working file system may have changed as it's not unmount, and in fact probably very soon after zeroing, wrote a good super replacement anyway. It seems the only missing thing we need is LVM metadata, maybe.) > So IMHO always use the primary superblock is the designed behavior. OK interesting. So in what case are the backup supers used? Only by `btrfs rescue super` or by explicit request, e.g. I notice even with an erased primary super signature, a `btrfs check -S1 --repair` does not cause the S0 super to be fixed up; and `btrfs rescue super` lacks an -S flag, so fixing accidentally wiped Btrfs super requires manual intervention. -- Chris Murphy
