Created attachment 107921 [details] gdb fullbacktrace When running "btrfs restore restore -i -v -t ..." using btrfs-progs from git on a corrupted file-system (the filesystem image has been created using dd while it was still mounted) I run into the following issue for almost every tree-node which doesn't immediatly abort. A few more information about the file-system is available at: http://pastebin.com/B2QUxhaj Unforutanetly btrs-image doesn't work, however I could upload it somewhere.
Please attach the(In reply to Clemens Eisserer from comment #0) > A few more information about the file-system is available at: > http://pastebin.com/B2QUxhaj Please attach this information into the bug.
Created attachment 109791 [details] btrfs-restore output
(In reply to Clemens Eisserer from comment #0) > When running "btrfs restore restore -i -v -t ..." using btrfs-progs from git > on a corrupted file-system (the filesystem image has been created using dd > while it was still mounted) I run into the following issue for almost every > tree-node which doesn't immediatly abort. Though it is possible to capture image of a mounted filesytem, if it's not mounted read-only, there is no guarantee that the data will be consistent. From the log: Well block 1109037056 seems great, but generation doesn't match, have=168269, want=168295 Well block 1436610560 seems great, but generation doesn't match, have=168271, want=168295 looks like the data on image are lacking a few metadata updates that were presumably present only in memory. We can't fix that, though making btrfs-restore more robust against corrupted images is desired, please upload the image.