Bug 61081

Summary:	btrfs-progs: Segfault in copy_one_extent when running btrfs restore
Product:	File System	Reporter:	Clemens Eisserer (linuxhippy)
Component:	btrfs	Assignee:	Josef Bacik (josef)
Status:	NEEDINFO ---
Severity:	normal	CC:	dsterba
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	3.11	Subsystem:
Regression:	No	Bisected commit-id:
Attachments:	gdb fullbacktrace btrfs-restore output

Description Clemens Eisserer 2013-09-09 18:46:35 UTC

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.

Comment 1 David Sterba 2013-09-27 08:44:27 UTC

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.

Comment 2 David Sterba 2013-09-27 08:44:56 UTC

Created attachment 109791 [details]
btrfs-restore output

Comment 3 David Sterba 2013-09-27 08:52:07 UTC

(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.