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:
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@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:
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@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@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
_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
12-17-2008, 09:13 PM
Jon Burgess
curious corruption 2-byte shift of all data
On Wed, 2008-12-17 at 15:35 -0500, Paul Raines wrote:
> Any
> fancy Linux device tricks I can do to make /dev/sdc1 shift everything
> by two bytes?
losetup -o 2
e.g.
[root@shark ~]# od -t x1 /dev/sda | head -n 1
0000000 eb 48 90 10 8e d0 bc 00 b0 b8 00 00 8e d8 8e c0
[root@shark ~]# losetup -o 2 /dev/loop0 /dev/sda
[root@shark ~]# od -t x1 /dev/loop0 | head -n 1
0000000 90 10 8e d0 bc 00 b0 b8 00 00 8e d8 8e c0 fb be
Jon
_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
12-17-2008, 09:28 PM
Paul Raines
curious corruption 2-byte shift of all data
On Wed, 17 Dec 2008, Jon Burgess wrote:
On Wed, 2008-12-17 at 15:35 -0500, Paul Raines wrote:
Any
fancy Linux device tricks I can do to make /dev/sdc1 shift everything
by two bytes?
losetup -o 2
e.g.
[root@shark ~]# od -t x1 /dev/sda | head -n 1
0000000 eb 48 90 10 8e d0 bc 00 b0 b8 00 00 8e d8 8e c0
[root@shark ~]# losetup -o 2 /dev/loop0 /dev/sda
[root@shark ~]# od -t x1 /dev/loop0 | head -n 1
0000000 90 10 8e d0 bc 00 b0 b8 00 00 8e d8 8e c0 fb be
Jon
Perfect! THanks.
Unfortunately it appears the filesystem is toast though and it was
not as simple as everything being shifted by 2 bytes. So I will
chalk it up as a loss.
[root@shadowfax ~]# losetup -o 2 /dev/loop7 /dev/sdc1
[root@shadowfax ~]# dumpe2fs -h /dev/loop7
dumpe2fs 1.39 (29-May-2006)
Filesystem volume name: ASALAZAR_USB1
Last mounted on: <not available>
Filesystem UUID: 549ade87-064b-46e8-8280-10c8a6f474b4
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: resize_inode filetype sparse_super large_file
Default mount options: (none)
Filesystem state: not clean with errors
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 61063168
Block count: 122096000
Reserved block count: 6104800
Free blocks: 46076684
Free inodes: 60915913
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 994
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 16384
Inode blocks per group: 512
Filesystem created: Thu Jun 26 13:03:39 2008
Last mount time: Tue Dec 16 15:31:21 2008
Last write time: Tue Dec 16 19:28:13 2008
Mount count: 35
Maximum mount count: 38
Last checked: Thu Jun 26 13:03:39 2008
Check interval: 15552000 (6 months)
Next check after: Tue Dec 23 12:03:39 2008
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Default directory hash: tea
Directory Hash Seed: e41ec746-def1-4d33-9a44-8aff8caef73b
ext2fs_read_bb_inode: A block group is missing an inode table
[root@shadowfax ~]# e2fsck -f -n /dev/loop7
e2fsck 1.39 (29-May-2006)
Group descriptors look bad... trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/loop7
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
12-21-2008, 12:25 PM
Christian Kujau
curious corruption 2-byte shift of all data
On Wed, 17 Dec 2008, Paul Raines wrote:
[root@shadowfax ~]# e2fsck -f -n /dev/loop7
e2fsck 1.39 (29-May-2006)
Group descriptors look bad... trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/loop7
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
Did you try one the alternatae superblocks? (mkfs.ext3 -n might help)
Last time I myself had to use this it did not work. So I'm really curious
if e2fsck -b actually works when this message appears.
Christian.
--
BOFH excuse #78:
Yes, yes, its called a design limitation
_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
12-22-2008, 03:18 AM
"Stephen Samuel"
curious corruption 2-byte shift of all data
It may be that only part of the filesystem has been shigted by 2 bytes.* Look through the partition and see if you can find blocks that look kike proper files/signatures.*
If that's a case later on in the filesystem, then do a binary search to see if you can figure out where the boundry is between the shifted and unshifted parts.
On Wed, Dec 17, 2008 at 2:28 PM, Paul Raines <raines@nmr.mgh.harvard.edu> wrote:
On Wed, 17 Dec 2008, Jon Burgess wrote:
On Wed, 2008-12-17 at 15:35 -0500, Paul Raines wrote:
Any
fancy Linux device tricks I can do to make /dev/sdc1 shift everything
by two bytes?
losetup -o 2
e.g.
[root@shark ~]# od -t x1 /dev/sda | head -n 1
0000000 eb 48 90 10 8e d0 bc 00 b0 b8 00 00 8e d8 8e c0
[root@shark ~]# losetup -o 2 /dev/loop0 /dev/sda
[root@shark ~]# od -t x1 /dev/loop0 | head -n 1
0000000 90 10 8e d0 bc 00 b0 b8 00 00 8e d8 8e c0 fb be
* * * *Jon
Perfect! THanks.
Unfortunately it appears the filesystem is toast though and it was
not as simple as everything being shifted by 2 bytes. *So I will
--
Stephen Samuel http://www.bcgreen.com
778-861-7641
_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
12-22-2008, 01:58 PM
Paul Raines
curious corruption 2-byte shift of all data
Yes, I tried. No luck.
On Sun, 21 Dec 2008, Christian Kujau wrote:
On Wed, 17 Dec 2008, Paul Raines wrote:
[root@shadowfax ~]# e2fsck -f -n /dev/loop7
e2fsck 1.39 (29-May-2006)
Group descriptors look bad... trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/loop7
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
Did you try one the alternatae superblocks? (mkfs.ext3 -n might help)
Last time I myself had to use this it did not work. So I'm really curious
if e2fsck -b actually works when this message appears.
Christian.
--
---------------------------------------------------------------
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
_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
12-22-2008, 02:01 PM
Paul Raines
curious corruption 2-byte shift of all data
I don't have a good way to find such a boundary so we ended up just
reformatting and calling it a loss.
I am more interested in finding out what caused it. Obviously reconnecting
a disk not properly unmounted and then writing to it again is not
the right thing to do, but I would not have expected the kind of
total corruption I saw.
On Sun, 21 Dec 2008, Stephen Samuel wrote:
It may be that only *part* of the filesystem has been shigted by 2 bytes.
Look through the partition and see if you can find blocks that look kike
proper files/signatures.
If that's a case later on in the filesystem, then do a binary search to see
if you can figure out where the boundry is between the shifted and unshifted
parts.
On Wed, Dec 17, 2008 at 2:28 PM, Paul Raines <raines@nmr.mgh.harvard.edu>wrote:
On Wed, 17 Dec 2008, Jon Burgess wrote:
On Wed, 2008-12-17 at 15:35 -0500, Paul Raines wrote:
Any
fancy Linux device tricks I can do to make /dev/sdc1 shift everything
by two bytes?
losetup -o 2
e.g.
[root@shark ~]# od -t x1 /dev/sda | head -n 1
0000000 eb 48 90 10 8e d0 bc 00 b0 b8 00 00 8e d8 8e c0
[root@shark ~]# losetup -o 2 /dev/loop0 /dev/sda
[root@shark ~]# od -t x1 /dev/loop0 | head -n 1
0000000 90 10 8e d0 bc 00 b0 b8 00 00 8e d8 8e c0 fb be
Jon
Perfect! THanks.
Unfortunately it appears the filesystem is toast though and it was
not as simple as everything being shifted by 2 bytes. So I will
chalk it up as a loss.
[root@shadowfax ~]# losetup -o 2 /dev/loop7 /dev/sdc1
[root@shadowfax ~]# dumpe2fs -h /dev/loop7
dumpe2fs 1.39 (29-May-2006)
Filesystem volume name: ASALAZAR_USB1
Last mounted on: <not available>
Filesystem UUID: 549ade87-064b-46e8-8280-10c8a6f474b4
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: resize_inode filetype sparse_super large_file
Default mount options: (none)
Filesystem state: not clean with errors
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 61063168
Block count: 122096000
Reserved block count: 6104800
Free blocks: 46076684
Free inodes: 60915913
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 994
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 16384
Inode blocks per group: 512
Filesystem created: Thu Jun 26 13:03:39 2008
Last mount time: Tue Dec 16 15:31:21 2008
Last write time: Tue Dec 16 19:28:13 2008
Mount count: 35
Maximum mount count: 38
Last checked: Thu Jun 26 13:03:39 2008
Check interval: 15552000 (6 months)
Next check after: Tue Dec 23 12:03:39 2008
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Default directory hash: tea
Directory Hash Seed: e41ec746-def1-4d33-9a44-8aff8caef73b
ext2fs_read_bb_inode: A block group is missing an inode table
[root@shadowfax ~]# e2fsck -f -n /dev/loop7
e2fsck 1.39 (29-May-2006)
Group descriptors look bad... trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/loop7
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
--
---------------------------------------------------------------
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
_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
curious corruption 2-byte shift of all data
