Re: read time tree block corruption detected

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2888 bytes --]



On 2019/12/30 下午5:21, Patrick Erley wrote:
> On Mon, Dec 30, 2019 at 9:09 AM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>>
>>
>>
>> On 2019/12/30 下午5:01, Patrick Erley wrote:
>>> On Mon, Dec 30, 2019 at 8:54 AM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>>>> On 2019/12/30 下午4:14, Patrick Erley wrote:
>>>>> On Mon, Dec 30, 2019 at 6:09 AM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>>>>>
>>>>> Should I also paste in the repair log?
>>>>>
>>>> Yes please.
>>>>
>>>> This sounds very strange, especially for the transid mismatch part.
>>>>
>>>> Thanks,
>>>> Qu
>>>>
>>>
>>>
>>>
>>> enabling repair mode
>>> WARNING:
>>>
>>>     Do not use --repair unless you are advised to do so by a developer
>>>     or an experienced user, and then only after having accepted that no
>>>     fsck can successfully repair all types of filesystem corruption. Eg.
>>>     some software or hardware bugs can fatally damage a volume.
>>>     The operation will start in 10 seconds.
>>>     Use Ctrl-C to stop it.
>>> 10 9 8 7 6 5 4 3 2 1parent transid verify failed on 499774464000
>>> wanted 3323349 found 3323340
>>> parent transid verify failed on 499774521344 wanted 3323349 found 3323340
>>> parent transid verify failed on 499774529536 wanted 3323349 found 3323340
>>
>> This message is from open_ctree(), which means the fs is already corrupted.
>>
>> Would you like to provide the history between last good btrfs check run
>> and --repair run?
>>
>> Thanks,
>> Qu
> 
> In theory, all I did was boot back into 5.1 and continued using the
> system. 

If that's the only thing before --repair (if there is only one repair
run, and output is exactly what you pasted), then I guess something
didn't go right in that 5.1 run?

Is that pasted output from the first --repair run?

If there is another run before the pasted output, then it could be
previous --repair.

Either way, I'm very sorry for the data loss...

> After you said I should go ahead and try to --repair, I
> rebooted into initramfs and ran the repair, then continued
> booting(which failed spectacularly, due to almost all of / being
> missing).  I then rebooted back into initramfs to assess what was
> going on, and made a liveusb (from which I'm sending this on that
> system).  Some 'background' on the FS: It was migrated from ext4 ~7?
> years ago, and has been moved between multiple discs and systems using
> dd.  Interesting point: The only files/folders that still exist in /
> were created after I migrated the filesystem.  If I can get /etc and
> maybe /var back, I'm golden (there are a few bits in each I don't
> include in my hot backups, so will have to go to offline storage to
> fetch them).

I'm afraid the only chance we left is btrfs-restore.

And normally for transid error, the chance is pretty low then.

Thanks,
Qu

> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 520 bytes --]