https://bugzilla.kernel.org/show_bug.cgi?id=78151 Theodore Tso <tytso@xxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tytso@xxxxxxx --- Comment #1 from Theodore Tso <tytso@xxxxxxx> --- This isn't a kernel bug, but in any case, the original purpose of e2image was to save the static file system metadata. I should update the man page to insert the word "static", but realistically, e2image -I was always a party trick. The form of the part trick was: e2image /dev/hda1 /tmp/hda1.e2i mke2fs -t ext4 /dev/hda1 e2image -I /dev/hda1.img /tmp/hda1.e2i e2fsck -f /dev/hda1.img The root directory will have been toasted, so all of the top-level directories will be in lost+found, but it will allow you to recover all of the files and most of the directory hierarchy with a minimum of effort. The e2image -r command will save the directory inodes as well, but we never implemented an e2image -I that would work with the raw e2image. The main utility of e2image -r is to extract enough file system metadata that you can run e2image on the image, for the purposes of debugging e2fsck problems (see the e2image man page for more details). What is it that you are trying to *do*? In general, the directory metadata tends to be fairly unstable, so the utility of backing up the directory inodes is relatively small. If you are trying to recover after an accidental rm -rf, unless the fs metadata snapshot was taken *right* before the rm -rf (which is highly unlikely if the rm -rf was accidental), it's not really going to work. If you are trying to protect against sysadmin mistakes, the best thing to do is traditional backups. The e2image file could potentially save you against a trashed inode table block, and so one of the things I've thought about doing is making e2fsck use a backup metadata block from an e2i file if the metadata checksum was incorrect. Again, unless the e2image file was very recent, it might not be that helpful, but it's better than nothing. But a selective use of a single trashed metadata block is much more likely to be useful than a wholesale use of all of the static metadata blocks via e2image -I. -- You are receiving this mail because: You are watching the assignee of the bug. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
