FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > EXT3 Users

 
 
LinkBack Thread Tools
 
Old 12-17-2008, 07:35 PM
Paul Raines
 
Default curious corruption 2-byte shift of all data

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@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 ...........@....
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@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
 
Old 12-17-2008, 09:13 PM
Jon Burgess
 
Default 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
 
Old 12-17-2008, 09:28 PM
Paul Raines
 
Default 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
 
Old 12-21-2008, 12:25 PM
Christian Kujau
 
Default 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
 
Old 12-22-2008, 03:18 AM
"Stephen Samuel"
 
Default 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

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



--
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
 
Old 12-22-2008, 01:58 PM
Paul Raines
 
Default 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
 
Old 12-22-2008, 02:01 PM
Paul Raines
 
Default 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
 

Thread Tools




All times are GMT. The time now is 11:42 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org