curious corruption 2-byte shift of all data

Paul Raines raines at nmr.mgh.harvard.edu
Wed Dec 17 20:35:47 UTC 2008


A user of ours had a USB drive with a ext3 filesystem he was using for backup 
of data.  He copied a ton of data to it and then was unable to mount the drive 
as he kept getting the message it was busy.  He uses the GNOME desktop and is 
not a "command line" user.  Having no other option he just disconnected the 
drive.  Later he reconnected it and says he started to remove of a bunch of 
the files.  14 hours later he came back and the remove operation was still 
going on and he could not stop it.  At this point he rebooted the box and then 
contacted me when the drive would not longer mount at all.

So I look at the partition table which still seems fine:

====================================================================
# fdisk -l /dev/sdc

Disk /dev/sdc: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

    Device Boot      Start         End      Blocks   Id  System
/dev/sdc1               1       60801   488384001   83  Linux
====================================================================

But a valid filesystem cannot be found.  I try to dumpe2fs it:

====================================================================
# dumpe2fs -h /dev/sdc1
dumpe2fs 1.39 (29-May-2006)
dumpe2fs: Bad magic number in super-block while trying to open /dev/sdc1
Couldn't find valid filesystem superblock.
[root at shadowfax ~]# dumpe2fs -h -ob32768 /dev/sdc1
dumpe2fs 1.39 (29-May-2006)
dumpe2fs: Bad magic number in super-block while trying to open /dev/sdc1
Couldn't find valid filesystem superblock.
====================================================================

and so on at a bunch of backup block locations.  No luck.
I then do a hex dump and find something interesting:

====================================================================
000003e0    00000000 00000000 00000000 00000000    ................
000003f0    00000000 00000000 00000000 00000000    ................
00000400    000000c0 a3038009 4707e026 5d000c13    ........G..&]...
00000410    bf02c980 a1030000 00000200 00000200    ................
00000420    00000080 00000080 00000040 00001910    ........... at ....
00000430    48499d47 48492300 260053ef 02000100    HI.GHI#.&.S.....
00000440    0000ebcb 6348004e ed000000 00000100    ....cH.N........
00000450    00000000 00000b00 00008000 00001000    ................
00000460    00000200 00000300 0000549a de87064b    ..........T....K
00000470    46e88280 10c8a6f4 74b44153 414c415a    F.......t.ASALAZ
00000480    41525f55 53423100 00000000 00000000    AR_USB1.........
00000490    00000000 00000000 00000000 00000000    ................
000004a0    00000000 00000000 00000000 00000000    ................
====================================================================

Doing a hexdump on other ext3 filesystems and looking at the magic file,
I see the bytes "53ef" are supposed to appear at 00000438.  Here they
appear 2 bytes further on (i.e. 0000043a).  SO I try something:

====================================================================
[root at shadowfax ~]# dd if=/dev/sdc1 bs=1 count=4096 skip=2 of=/tmp/sdc1.data 
4096+0 records in
4096+0 records out
4096 bytes (4.1 kB) copied, 0.01094 seconds, 374 kB/s
[root at shadowfax ~]# file /tmp/sdc1.data
/tmp/sdc1.data: Linux rev 1.0 ext2 filesystem data (mounted or unclean) 
(errors) (large files)
====================================================================

Looking at the fs label, 'ASALAZAR_USB1', it is also offset 2 bytes
to the position I see in other valid ext3 filesystems I have labeled.
So everythings seems shifted 2 bytes.

Any idea how this happened?  Any idea how to easily fix it?  Any
fancy Linux device tricks I can do to make /dev/sdc1 shift everything
by two bytes?

Right now I can only think of doing a dump shifted by 2 bytes of
this disk to another disk and see if can then mount that disk.

-- 
---------------------------------------------------------------
Paul Raines                email: raines at nmr.mgh.harvard.edu
MGH/MIT/HMS Athinoula A. Martinos Center for Biomedical Imaging
149 (2301) 13th Street     Charlestown, MA 02129	    USA





More information about the Ext3-users mailing list