dd if=/dev/zero of=e4.dat bs=1 count=1 seek=999999999 mkfs.ext4 e4.dat mount e4.dat /mnt rsync -a /usr/include/ /mnt/ umount /mnt e2image e4.dat e4.img mount e4.dat /mnt rm -r /mnt/* umount /mnt e2image -I e4.dat e4.img # Filesystem in e4.dat is unusable. # after fsck -y e4.dat and mounting it, # in /mnt/lost+found there are lots of files+dirs, # but with names like #12345 # expected that all metadata would be recovered? # is there an e4image? Kind regards, J.B.
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.
Thanks a lot. I've stored tons of data on an almost static ext4 filesystem. Just in the rare case when adding more data (deletion does not occur in this case), the filesystem gets modified. Additionally, there's a md5 database for each file (out-of-band), so *tought* recovery could be done quick in case of "admin errors" or "head crash on large inode region". (Multiple versions of e2image would be requierd then, of course). Kind regards, Jochen
PS: in addition to tape backup, of course.
The simplest and easist thing if this is what you are trying to do is to store the inode number along with the md5 checksum in your offline database. Now if things go really go really bad, you can do this to recover files: debugfs -id /dev/sda1 /u1/sda1.e2i debugfs: dump <12345> filename-for-inode-12345