[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: 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

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:

fancy Linux device tricks I can do to make /dev/sdc1 shift everything
by two bytes?

losetup -o 2


[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


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

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]