curious corruption 2-byte shift of all data

[Paul Raines]

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