[Matthew Burke]
> On Sun, 28 May 2000, James Manning wrote:
> > [Matthew Burke]
> > > e2fsck 1.18, 11-nov-1999 for EXT2 FS 0.5b, 95/08/09
> > > e2fsck: Attempt to read block from filesystem resulted in short read while
> > > trying to open /dev/md1
> > > Could this be a zero-length partition?
>
> mdstat:
>
> Personalities : [raid0]
> read_ahead 1024 sectors
> md0 : active raid0 hdc1[1] hda3[0] 1606272 blocks 64k chunks
> unused devices: <none>
No active /dev/md1, so e2fsck failing is normal.
> hda: ST36531A, 6204MB w/128kB Cache, CHS=790/255/63, (U)DMA
> hdb: IBM-DJNA-351520, 14664MB w/430kB Cache, CHS=1869/255/63, (U)DMA
> hdc: ST36531A, 6204MB w/128kB Cache, CHS=13446/15/63, (U)DMA
>
> *** edited note from matt - the CHS values have always been different for
> some unknown reason...
AFAIK, you simply have one drive in LBA mode and not the other.
in my exp, just a bios setting difference but you're under 8GB anyway
so I'm not sure it really makes a diff.
> autodetecting RAID arrays
> (read) hda3's sb offset: 787072 [events: 00000063]
> (read) hda4's sb offset: 5470016 [events: 0000005e]
> (read) hdc1's sb offset: 819200 [events: 00000063]
> (read) hdc3's sb offset: 5470016 [events: 00000000]
> md: invalid superblock checksum on hdc3
Sure makes it look like hdc3 has some major issues. It has a partition
type of fd, but invalid raid superblock. Makes me wonder if e2fsck
didn't get run on hdc3 itself and it "fixed" that last part (hope not
since it may have done some real superblock damage). hdc itself looks
ok since hdc3 doesn't seem to have any problems, so I don't think it's
an actual drive problem. Unfortunately, since it appears that the raid
superblock (at a minimum) is broken on hdc3, the only thing I can think
to recommend is
- mkraid --force /dev/md1 (rewrites raid superblocks)
- try to raidstart /dev/md1 (and hope that the real data is ok)
- mount -o ro /dev/md1 /mnt (see if it looks ok)
There is the chance that the partition table got slightly corrupted
and hdc3's entry has an incorrect value (unlikely, though, since
the size matches hda4). Make sure your raidtab matches md1's actual
devices before running the --force, of course.
Note that "normally" the superblock checksum is fine and the update
counter is only a few off from the most recent, so I want to stress
that if there is something strange wrong (like a partition table
screwup), the writing of the raid superblocks can corrupt data.
If this all makes you nervous, feel free to see what others may
recommend... I've certainly never dealt with this exact kind of situation
before (array recovery attempts for a raid0 array :)
James
