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