Qu Wenruo <quwenruo.btrfs@gmx.com> 於 2020年2月6日 週四 上午9:13寫道：
> Please keep in mind that, if you post dmesg, the first time such error
> happens is the most important.
> Not something after you modified the fs by btrfs check --repair.

Thanks for your advice. I'll keep in my mind. :)


> >
> > Feb  3 15:38:24 rescue kernel: [ 8731.172674] BTRFS critical (device
> > bcache2): corrupt leaf: root=23146 block=19498503094272 slot=8,
> > invalid key objectid: has 18446744073709551606 expect 6 or [256,
> > 18446744073709551360] or 18446744073709551604
>
> This is message is even earlier than your initial report, and it's more
> important.
> This means you have a bad inode item with objectid EXTENT_CSUM_OBJECTID.
>
> This is a bigger problem.

It sounds bad. Is it possible to save the data or part of them?


> Are you sure that is the very first error message you hit?

My .bash_history doesn't show timestamp so I'm not really sure which
critical/error
message is exactly right after the first `btrfs check --repair`. I
tried to make log file
smaller and excerpted only btrfs messages before the first critical
message in the
attachment. I'm not so familiar with mailing list. Could you see `btrfs_.log`?


> > rescue ~$ btrfs check /dev/bcache4
> > Opening filesystem to check...
> > Checking filesystem on /dev/bcache4
> > UUID: 0b79cf54-c424-40ed-adca-bd66b38ad57a
> > [1/7] checking root items
> > Error: could not find extent items for root 257
> > ERROR: failed to repair root items: No such file or directory
>
> This part is from a special repair for a regression in 3.17.
>
> I guess we should not enable it by default.
> That will be another patch for btrfs-progs.

Is this patch safe for saving my btrfs? If it is, I can build btrfs-progs.


Regards,
Chiung-Ming Huang