Accidentally issued "mkswap" on ext3 fs -- recovery possible?
Wolfram Schlich
lists at wolfram.schlich.org
Fri Jul 8 16:03:37 UTC 2005
Hi,
I accidentally issued "mkswap" on a used ext3 fs partition (~30G) :-/
I have analyzed the behaviour of mkswap using two test files and it
appears to only change "some" bytes:
--8<--
--- swap2.xxd 2005-07-04 21:00:10.157261360 +0200
+++ swap1.xxd 2005-07-04 21:00:01.894517488 +0200
@@ -62,7 +62,7 @@
00003d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00003e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00003f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
-0000400: 0000 0000 0000 0000 0000 0000 0000 0000 ................
+0000400: 0100 0000 ff09 0000 0000 0000 0000 0000 ................
0000410: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000420: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000430: 0000 0000 0000 0000 0000 0000 0000 0000 ................
@@ -253,7 +253,7 @@
0000fc0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000fd0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000fe0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
-0000ff0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
+0000ff0: 0000 0000 0000 5357 4150 5350 4143 4532 ......SWAPSPACE2
0001000: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0001010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0001020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
--8<--
I created an image (hdb1.img) of the damaged partition using dd
and tried to work with various tools on it.
Here is the output of 'fsck.ext3 -n -v hdb1.img':
--8<--
e2fsck 1.35 (28-Feb-2004)
Couldn't find ext2 superblock, trying backup blocks...
hdb1.img was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong for group #0 (24043, counted=0).
Fix? no
Free blocks count wrong for group #1 (32250, counted=0).
Fix? no
Free blocks count wrong for group #2 (32253, counted=0).
Fix? no
Free blocks count wrong for group #3 (32250, counted=158).
Fix? no
Free blocks count wrong for group #4 (32253, counted=8).
Fix? no
Free blocks count wrong for group #5 (32250, counted=28).
Fix? no
Free blocks count wrong for group #6 (32253, counted=6822).
Fix? no
Free blocks count wrong for group #7 (32250, counted=10428).
Fix? no
Free blocks count wrong for group #8 (32253, counted=11170).
Fix? no
Free blocks count wrong for group #9 (32250, counted=4239).
Fix? no
Free blocks count wrong for group #10 (32253, counted=24482).
Fix? no
Free blocks count wrong for group #11 (32253, counted=21184).
Fix? no
Free blocks count wrong for group #12 (32253, counted=25657).
Fix? no
Free blocks count wrong for group #13 (32253, counted=13674).
Fix? no
Free blocks count wrong for group #14 (32253, counted=15007).
Fix? no
Free blocks count wrong for group #15 (32253, counted=11366).
Fix? no
[ removed many lines, complete log file at
http://wolfram.schlich.org/tmp/fsck.ext3_-n_-v_hdb1.img ]
Free inodes count wrong for group #213 (16416, counted=14498).
Fix? no
Directories count wrong for group #213 (0, counted=241).
Fix? no
Free inodes count wrong for group #214 (16416, counted=14524).
Fix? no
Directories count wrong for group #214 (0, counted=126).
Fix? no
Free inodes count wrong for group #215 (16416, counted=14441).
Fix? no
Directories count wrong for group #215 (0, counted=114).
Fix? no
Free inodes count wrong for group #216 (16416, counted=15214).
Fix? no
Directories count wrong for group #216 (0, counted=99).
Fix? no
Free inodes count wrong for group #217 (16416, counted=14898).
Fix? no
Directories count wrong for group #217 (0, counted=216).
Fix? no
Free inodes count wrong for group #218 (16416, counted=14878).
Fix? no
Directories count wrong for group #218 (0, counted=187).
Fix? no
Free inodes count wrong for group #219 (16416, counted=16033).
Fix? no
Directories count wrong for group #219 (0, counted=37).
Fix? no
Free inodes count wrong for group #220 (16416, counted=14949).
Fix? no
Directories count wrong for group #220 (0, counted=128).
Fix? no
Free inodes count wrong for group #221 (16416, counted=15167).
Fix? no
Directories count wrong for group #221 (0, counted=102).
Fix? no
Free inodes count wrong for group #222 (16416, counted=15908).
Fix? no
Directories count wrong for group #222 (0, counted=79).
Fix? no
Free inodes count wrong for group #223 (16416, counted=14719).
Fix? no
Directories count wrong for group #223 (0, counted=117).
Fix? no
Free inodes count wrong for group #224 (16416, counted=14212).
Fix? no
Directories count wrong for group #224 (0, counted=165).
Fix? no
Free inodes count wrong for group #225 (16416, counted=14104).
Fix? no
Directories count wrong for group #225 (0, counted=118).
Fix? no
Free inodes count wrong for group #226 (16416, counted=14634).
Fix? no
Directories count wrong for group #226 (0, counted=227).
Fix? no
Free inodes count wrong for group #227 (16416, counted=14616).
Fix? no
Directories count wrong for group #227 (0, counted=198).
Fix? no
Free inodes count wrong for group #228 (16416, counted=14622).
Fix? no
Directories count wrong for group #228 (0, counted=139).
Fix? no
Free inodes count wrong (3759253, counted=3348765).
Fix? no
hdb1.img: ********** WARNING: Filesystem still has errors **********
11 inodes used (0%)
7136 non-contiguous inodes (64872.7%)
# of inodes with ind/dind/tind blocks: 50303/388/0
126175 blocks used (1%)
0 bad blocks
0 large files
377976 regular files
30868 directories
0 character device files
0 block device files
13 fifos
48 links
1632 symbolic links (1631 fast symbolic links)
0 sockets
--------
410537 files
--8<--
I guess if I would let fsck "fix" it, the damage would be bigger than
the benefit -- those numbers look scary to me:
--8<--
11 inodes used (0%)
7136 non-contiguous inodes (64872.7%)
# of inodes with ind/dind/tind blocks: 50303/388/0
126175 blocks used (1%)
--8<--
I haven't even tried to have it "fix" the fs on the image file.
What do you think?
e2salvage doesn't recognize any superblocks (not even the backup
superblocks dumpe2fs happily uses to display some information on the
fs image), maybe because it's not an ext2 but ext3 fs. Well.
Currently I'm running e2retrieve on the image to see whether this is
able to do some recovery, but no results yet.
Any suggestions? It's hard to believe that those few changed bytes
should make the whole fs unrecoverable, isn't it?
Thanks in advance!
--
Wolfram Schlich
More information about the Ext3-users
mailing list