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? The data and meta data should be raid1, and none of the drives have any io errors of any kinds in their SMART log. Thank you for your guidance.
Attachment:
signature.asc
Description: OpenPGP digital signature
