> -----Original Message----- > From: linux-btrfs-owner@xxxxxxxxxxxxxxx [mailto:linux-btrfs- > owner@xxxxxxxxxxxxxxx] On Behalf Of Chris Murphy > Sent: Thursday, 6 August 2015 2:54 AM > To: Sonic <sonicsmith@xxxxxxxxx> > Cc: Btrfs BTRFS <linux-btrfs@xxxxxxxxxxxxxxx>; Hugo Mills > <hugo@xxxxxxxxxxxxx> > Subject: Re: BTRFS disaster (of my own making). Is this recoverable? > > On Wed, Aug 5, 2015 at 6:31 AM, Sonic <sonicsmith@xxxxxxxxx> wrote: > > On Tue, Aug 4, 2015 at 4:23 PM, Sonic <sonicsmith@xxxxxxxxx> wrote: > >> Seems that if there was someway to edit something in those first > >> overwritten 32MB of disc 2 to say "hey, I'm really here, just a bit > >> screwed up" maybe some of the recovery tools could actually work. > > > > Just want to reiterate this thought. > > > > The basic error in most cases with the tools at hand is that Disc 2 is > > missing so there's little the tools can do. Somewhere in those first > > 32MB should be something to properly identify the disc as part of the > > array. > > Yes but it was probably uniquely only on that disk, because there's no > redundancy for metadata or system chunks. Therefore there's no copy on > the other disk to use as a model. The btrfs check command has an option to > use other superblocks, so you could try that switch and see if it makes a > difference but it sounds like it's finding backup superblocks automatically. > That's the one thing that is pretty much always duplicated on the same disk; > for sure the first superblock is munged and would need repair. But there's > still other chunks missing... so I don't think it'll help. Would it be possible to store this type of critical information twice on each disk, at the beginning and end? I thought BTRFS already did that, but I might be thinking of some other filesystem. I've had my share of these types of oops! moments as well. Paul. ��.n��������+%������w��{.n�����{����n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
