curious corruption 2-byte shift of all data
Paul Raines
raines at nmr.mgh.harvard.edu
Mon Dec 22 15:01:13 UTC 2008
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 at 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 at 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 at shark ~]# losetup -o 2 /dev/loop0 /dev/sda
>>> [root at 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 at shadowfax ~]# losetup -o 2 /dev/loop7 /dev/sdc1
>> [root at 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 at 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 at 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
More information about the Ext3-users
mailing list