deep recovery and embedded filesystem images [LWN.net]

deep recovery and embedded filesystem images

Posted Dec 3, 2011 17:57 UTC (Sat) by walex (subscriber, #69836)
In reply to: Improving ext4: bigalloc, inline data, and metadata checksums by mpr22
Parent article: Improving ext4: bigalloc, inline data, and metadata checksums

That's an interesting case. ReiserFS was designed to be very robust in the face of partial data loss, allowing for a reconstruction of the file system metadata from recognizable copies embedded in the files themselves.

Thus the contents of an embedded ReiserFS image will look like lost files from the containing filesystem, if the option to reconstruct metadata is enabled.

Running man reiserfsck is advised before doing recovery on a damaged ReiserFS image. Paying particular attention to the various mentions of --rebuild-tree may be wise.

In other words there is nothing to fix, except a lack of awareness of one of the better features of ReiserFS, or perhaps a lack of a specific warning.

(Log in to post comments)

deep recovery and embedded filesystem images

Posted Dec 4, 2011 1:05 UTC (Sun) by nix (subscriber, #2304) [Link]

You're the only person I have ever heard call reiserfsck's propensity to fuse disk images into an unholy union with their containing filesystem a *feature*.

I don't think it was ever any part of reiserfsck's design to "reconstruct[] file system metadata from recognizable copies embedded in the files themselves" because nobody ever does that (how many copies of your inode tables do you have written to files in your filesystem for safety? None, that's right). It's more that reiserfsck --rebuild-tree simply scanned the whole partition for things that looked like btree nodes, and if it found them, it assumed they came from the same filesystem, and not from a completely different filesystem that happened to be merged into it -- there was no per-filesystem identifier in each node or anything like that, so they all got merged together.

This is plainly a design error, but equally plainly not one that would have been as obvious when reiserfs was designed as it is now, when disks were smaller than they are today and virtual machine images much rarer.

If you want some real fun, try a reiserfs filesystem with an ext3 filesystem inside it and another reiserfs filesystem embedded in that. To describe what reiserfsck --rebuild-tree on the outermost filesystem does to the innermost two would require using words insufficiently family-friendly for this site (though it is extremely amusing if you have nothing important on the fs).

Rebuild tree a useful feature with side-effects.

Posted Dec 8, 2011 4:26 UTC (Thu) by gmatht (guest, #58961) [Link]

I don't think that merging filesystems was meant to be a feature, but rather the rebuild-tree is useful feature that other fscks don't have.

If someone has stored all their precious photos and media files on a disk, and the metadata is trashed, then rebuilding the tree should get them their files back where a regular fsck wouldn't. I wouldn't trust --rebuild-tree not to add random files at the best of times, for example, I understand that it restores deleted files [1] which you probably don't want to do in a routine fsck. If, on the other hand, you've just found out that all your backups are on write-only media, rebuilding a tree from leaves could save you from losing years of work. It would be even better if it didn't merge partitions, but is still better than nothing if used as a last resort.

I think it would also be better if it encouraged you to rebuild the tree onto an entirely new partition.

[1] http://www.linuxquestions.org/linux/answers/Hardware/Reis...

Rebuild tree a useful feature with side-effects.

Posted Dec 8, 2011 5:35 UTC (Thu) by tytso (subscriber, #9993) [Link]

The fsck for ext2/3/4 doesn't have this feature because it doesn't need it. One of the tradeoffs of using a dynamic inode table (since in reiserfs it is stored as part of the btree) is if you lose the root node of the file system, you have no choice but to search the entire disk looking for nodes that appear to belong to the file system b-tree.

With ext 2/3/4, we have a static inode table. This does have some disadvantages, but the advantage is that it's much more robust against file system damage, since the location of the metadata is much more predictable.