That sucks :-( The only reason I had hope for /etc and /var was they show up in btrfs check as not having a parent and i figured I could reparent them onto the new / and have a chance of extracting something useful from them. I guess I'll plan on grabbing images of the FS tomorrow and starting a full rebuild. Hopefully someone will chime in with a way to get /etc/ and /var/ before I reach the point I need them. On Mon, Dec 30, 2019 at 9:27 AM Qu Wenruo <quwenruo.btrfs@xxxxxxx> wrote: > > > > 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 > > > >
