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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 17 Jun 2014 12:41:54 +0000
From:	bugzilla-daemon@...zilla.kernel.org
To:	linux-ext4@...r.kernel.org
Subject: [Bug 78151] e2image -I does not work on ext4?

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

Theodore Tso <tytso@....edu> changed:

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

--- Comment #1 from Theodore Tso <tytso@....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.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html