* A rescue tool for btrfs
@ 2010-12-16 23:18 Michael Niederle
2010-12-17 0:39 ` Chris Mason
2010-12-20 12:18 ` Bryan Østergaard
0 siblings, 2 replies; 3+ messages in thread
From: Michael Niederle @ 2010-12-16 23:18 UTC (permalink / raw)
To: linux-btrfs
Hi!
Last week I crashed a btrfs file system. I didn't lose a lot of data because I
had current backups of most data and a full backup from a month ago.
But I thought it would be a nice idea to have a rescue tool! Currently I have a
first release of this tool (surely buggy and runnning on little endian
architectures only).
The tool is written in C using the header files from the btrfs userland tools.
I use a wrapper (written in a script language) to restore whole directories.
Such a wrapper could also detect hard links and handle them correctly.
btrfs_rescue implements all disk accesses itself and tries to access only the
absolute minimum of necessary data structures to avoid the pitfalls that lurk
somewhere in the destroyed file system. So you can rescue parts of a destroyed
file system even if the file system driver cannot mount it anymore.
The source code is available under
http://simplux.org/downloads/btrfs_rescue.c
Here is a short overview of the tool's usage:
Usage:
btrfs_rescue --help
shows this short description of available commands
btrfs_rescue volumes <device>
displays a list of all subvolumes
btrfs_rescue dir <device> <volume>
shows the contents of the root directory
btrfs_rescue dir <device> <volume> <inode>
shows the contents of the directory with the specified inode number
btrfs_rescue stat <device> <volume> <inode>
displays the status of the file with the specified inode
btrfs_rescue cp [--preserve] [--large] <device> <volume> <inode> <filename>
creates a copy of the file specified by the inode number under the
specified file name
The cp-command can copy regular files as well as symbolic links, block and
character devices. When copying a directory, only the directory node itself is
copied but not its contents!
The "--preserve" option preserves access rights, ownership, access time and
modification time of the file.
The "--large" option allows copying of files larger than 100MB.
(A very large file size could stem from the filesystem destruction.)
An example output of the above commands:
# btrfs_rescue volumes /dev/sde2
5 (generation 227542)
256 (generation 227106)
257 (generation 227553)
258 (generation 227105)
259 (generation 227506)
260 (generation 225276)
261 (generation 224231)
...
314 (generation 226751)
315 (generation 226752)
316 (generation 227104)
317 (generation 227105)
318 (generation 227106)
# btrfs_rescue dir /dev/sde2 5
dev: 584 (directory)
.backups: 256 (directory)
downloads: 259 (directory)
boot: 381 (directory)
lib: 3504 (directory)
sbin: 18685 (directory)
save2: 260 (directory)
usr: 75153 (directory)
opt: 14258 (directory)
destination: 1056921 (directory)
.joe_state: 1122321 (regular file)
data: 583 (directory)
bin: 263 (directory)
initrd: 257 (directory)
save: 259 (directory)
home: 258 (directory)
net: 14257 (directory)
.bash_history: 1325987 (regular file)
etc: 585 (directory)
source: 1056920 (directory)
var: 18959 (directory)
tmp: 262 (directory)
sys: 261 (directory)
mnt: 14256 (directory)
proc: 258 (directory)
root: 257 (directory)
cmds: 408 (directory)
# btrfs_rescue dir /dev/sde2 5 584
vbi: 362470 (symbolic link)
dri: 1320381 (directory)
dmfm2: 361934 (character device)
mixer1: 362155 (character device)
sequencer: 362269 (character device)
hdb4: 361984 (block device)
hdc7: 361997 (block device)
hda1: 361964 (block device)
...
loop0: 362037 (block device)
sda9: 362218 (block device)
parport0: 362166 (character device)
ippp2: 362026 (character device)
nvram: 362165 (character device)
midi03: 362152 (character device)
pts: 362176 (directory)
# btrfs_rescue stat /dev/sde2 5 362152
type: 21b0
character device
major: 0xe
minor: 0x32
size: 0
allocated: 0
links: 1
uid: 17
gid: 0
mode: 0660
access: 2007-07-17 18:58:42.000000000 +0200
modify: 2007-07-17 18:58:42.000000000 +0200
change: 2010-05-17 23:33:23.720827790 +0200
Greetings, Michael
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: A rescue tool for btrfs
2010-12-16 23:18 A rescue tool for btrfs Michael Niederle
@ 2010-12-17 0:39 ` Chris Mason
2010-12-20 12:18 ` Bryan Østergaard
1 sibling, 0 replies; 3+ messages in thread
From: Chris Mason @ 2010-12-17 0:39 UTC (permalink / raw)
To: Michael Niederle; +Cc: linux-btrfs
Excerpts from Michael Niederle's message of 2010-12-16 18:18:49 -0500:
> Hi!
>
> Last week I crashed a btrfs file system. I didn't lose a lot of data because I
> had current backups of most data and a full backup from a month ago.
>
> But I thought it would be a nice idea to have a rescue tool! Currently I have a
> first release of this tool (surely buggy and runnning on little endian
> architectures only).
>
> The tool is written in C using the header files from the btrfs userland tools.
> I use a wrapper (written in a script language) to restore whole directories.
> Such a wrapper could also detect hard links and handle them correctly.
>
> btrfs_rescue implements all disk accesses itself and tries to access only the
> absolute minimum of necessary data structures to avoid the pitfalls that lurk
> somewhere in the destroyed file system. So you can rescue parts of a destroyed
> file system even if the file system driver cannot mount it anymore.
>
> The source code is available under
>
> http://simplux.org/downloads/btrfs_rescue.c
A very good idea, its the same direction I'm going with the btrfsck code
right now. The basic idea is that it is much more reliable (and faster
to implement) to pull data off the disk than it is to try and fix it in
place. I'm growing some in place fixes as well for the really common
errors (especially power crashes w/o barriers)
If you're interested in doing more on this, I'll have my code up
shortly.
-chris
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: A rescue tool for btrfs
2010-12-16 23:18 A rescue tool for btrfs Michael Niederle
2010-12-17 0:39 ` Chris Mason
@ 2010-12-20 12:18 ` Bryan Østergaard
1 sibling, 0 replies; 3+ messages in thread
From: Bryan Østergaard @ 2010-12-20 12:18 UTC (permalink / raw)
To: Michael Niederle; +Cc: linux-btrfs
On 17/12/2010, at 00.18, Michael Niederle wrote:
> Hi!
>=20
> Last week I crashed a btrfs file system. I didn't lose a lot of data =
because I
> had current backups of most data and a full backup from a month ago.
>=20
> But I thought it would be a nice idea to have a rescue tool! Currentl=
y I have a
> first release of this tool (surely buggy and runnning on little endia=
n
> architectures only).
>=20
Thank you for writing this tool. It was able to save some 80% of all da=
ta from a=20
very broken btrfs filesystem. I could mount the filesystem but it would=
hang after=20
just a few accesses with thousands of parent transid verify failed mess=
ages and
btrfsck just exited immediately with some huge negative number as the o=
nly=20
indication of what was wrong. Using the btrfsck -s $number option also =
didn't=20
help but your tool seemed to do the job just fine.
I still have the broken filesystem as I'm interested to see what Chris =
Masons new=20
btrfsck code can do with it so if anybody is interested in further debu=
gging I can=20
probably help with that.
Regards,
Bryan =D8stergaard
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2010-12-20 12:18 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-12-16 23:18 A rescue tool for btrfs Michael Niederle
2010-12-17 0:39 ` Chris Mason
2010-12-20 12:18 ` Bryan Østergaard
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.