On 2019/12/30 下午5:21, Patrick Erley wrote: > On Mon, Dec 30, 2019 at 9:09 AM Qu Wenruo <quwenruo.btrfs@xxxxxxx> wrote: >> >> >> >> On 2019/12/30 下午5:01, Patrick Erley wrote: >>> On Mon, Dec 30, 2019 at 8:54 AM Qu Wenruo <quwenruo.btrfs@xxxxxxx> wrote: >>>> On 2019/12/30 下午4:14, Patrick Erley wrote: >>>>> On Mon, Dec 30, 2019 at 6:09 AM Qu Wenruo <quwenruo.btrfs@xxxxxxx> 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:
signature.asc
Description: OpenPGP digital signature
