Re: confusing behavior when supers mismatch

[Chris Murphy <lists@colorremedies.com>]

On Sun, Mar 10, 2019 at 7:18 PM Qu Wenruo <quwenruo.btrfs@gmx.com> 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