On 2019/10/1 上午9:41, Remi Gauvin wrote: > On 2019-09-30 9:30 p.m., Qu Wenruo wrote: >> >> >> On 2019/10/1 上午5:08, Remi Gauvin wrote: >>> Mounting the FS after that btrfs check, kernel 5.3.1, here is the dmesg log: >> >> As that btrfs check shows, your extent tree is corrupted. >> Quite some backref is lost, thus no wonder some write opeartion would >> cause problem. >> >> In that case, it looks like only extent tree is corrupted, and no >> transid error. >> >> If you have data backed up, you would like to btrfs check --repair to >> see if it can repair them. >> >> Thanks, >> Qu > > > This is itself a back-up system, but not wishing to tempt fate, I'm > going to have to create a working substitute before I do anything risky > with it. It would take me several days and lots of travel to re-aquire > them. > > Any idea what could have happened?
Maybe some existing bugs, since it's an older kernel. But at least, no tree relationship corruption. So you should be pretty OK. You could try btrfs check --init-extent-tree, as I see no error report from fs tree check. Since it's extent tree only mismatch, you can in fact mount the fs RO and grab all data. > The data and meta data should be > raid1, and none of the drives have any io errors of any kinds in their > SMART log. It's indeed a symptom of btrfs kernel module bug. But at least looks repairable. Thanks, Qu > > Thank you for your guidance. > > > >
signature.asc
Description: OpenPGP digital signature
