[Bug 78151] New: e2image -I does not work(?)

[Bug 78151] New: e2image -I does not work(?)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=78151

            Bug ID: 78151
           Summary: e2image -I does not work(?)
           Product: File System
           Version: 2.5
    Kernel Version: 3.8.0-42-generic (Xubuntu 12.04)
          Hardware: All
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: ext4
          Assignee: fs_ext4@kernel-bugs.osdl.org
          Reporter: barth@ub.uni-heidelberg.de
        Regression: No

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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 78151] e2image -I does not work on ext4?

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=78151

J. B. <barth@ub.uni-heidelberg.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|e2image -I does not work(?) |e2image -I does not work on
                   |                            |ext4?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 78151] e2image -I does not work on ext4?

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=78151

Theodore Tso <tytso@mit.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tytso@mit.edu

--- Comment #1 from Theodore Tso <tytso@mit.edu> ---
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.

[Bug 78151] e2image -I does not work on ext4?

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=78151

--- Comment #2 from J. B. <barth@ub.uni-heidelberg.de> ---
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

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 78151] e2image -I does not work on ext4?

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=78151

--- Comment #3 from J. B. <barth@ub.uni-heidelberg.de> ---
PS: in addition to tape backup, of course.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 78151] e2image -I does not work on ext4?

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=78151

--- Comment #4 from Theodore Tso <tytso@mit.edu> ---
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

-- 
You are receiving this mail because:
You are watching the assignee of the bug.