IDE SWRaid array unmountable

Hi Folks,

On my RH9 box, I have this:
(Enlight 8950, A7v133, 512Mb, Duron900, 4@SilentDrive2002, 3@Samsung 
SP1614N, 2@Samsung SP1203N, ENP-0730 power, 2@Zalman PS80252H, KCZ2700)

hda:  120G
hde:  160G
hdf:  160G
hdg:  160G
hdh:  120G  (cron mnt/rsync/umnt backup drive, aggressive idle spindown)

I have been attempting to hook the 160s in to a Raid5, to some failure.

Here's what I've done:

> [root@fishy root]# mdadm -Cv /dev/md0 -l5 -n3 -c128 /dev/hd{e,f,g}1

It dutifully said:

> [root@fishy root]# cat /proc/mdstat
> Personalities : [raid5]
> read_ahead 1024 sectors
> md0 : active raid5 hdg1[3] hdf1[1] hde1[0]
>       312576512 blocks level 5, 128k chunk, algorithm 2 [3/2] [UU_]
>       [>....................]  recovery =  1.3% (2177116/156288256)
> finish=249.4min speed=10296K/sec
> unused devices: <none>

> [root@fishy root]# mdadm --misc --detail /dev/md0
> /dev/md0:
>         Version : 00.90.00
>   Creation Time : Wed Sep 15 00:06:48 2004
>      Raid Level : raid5
>      Array Size : 312576512 (298.10 GiB 320.12 GB)
>     Device Size : 156288256 (149.05 GiB 160.08 GB)
>    Raid Devices : 3
>   Total Devices : 4
> Preferred Minor : 0
>     Persistence : Superblock is persistent
> 
>     Update Time : Wed Sep 15 00:06:48 2004
>           State : dirty, no-errors
>  Active Devices : 2
> Working Devices : 3
>  Failed Devices : 1
>   Spare Devices : 1
> 
>          Layout : left-symmetric
>      Chunk Size : 128K
> 
>     Number   Major   Minor   RaidDevice State
>        0      33        1        0      active sync   /dev/hde1
>        1      33       65        1      active sync   /dev/hdf1
>        2       0        0        2      faulty
>        3      34        1        3        /dev/hdg1
>            UUID : f0d5fd14:b3f45ab1:ed1e284e:b57ba53f

Everything we expect, so far.

4 hours or so later, I did:

> [root@fishy root]# mkfs.ext3 /dev/md0
> mke2fs 1.32 (09-Nov-2002)
> Filesystem label=
> OS type: Linux
> Block size=4096 (log=2)
> Fragment size=4096 (log=2)
> 39075840 inodes, 78144128 blocks
> 3907206 blocks (5.00%) reserved for the super user
> First data block=0
> 2385 block groups
> 32768 blocks per group, 32768 fragments per group
> 16384 inodes per group
> Superblock backups stored on blocks:
>         32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
>         4096000, 7962624, 11239424, 20480000, 23887872, 71663616

Ten minutes later, it was done that part as well.  No messages to the 
console or syslog in this stage at all.

However, then I got a bit saucy:

> mount /dev/md0 /mnt/floppy
> cp -a /home /mnt/floppy

After a bit of time, maybe 20 min, the copy blew:

> Message from syslogd@fishy at Wed Sep 15 05:08:34 2004 ...
> fishy kernel: Assertion failure in journal_forget_R89e31bd9() at
> transaction.c:1255: "!jh->b_committed_data"

The kernel panicked a bit, the drive was unusable but couldn't be 
unmounted, and a reboot was required to fix it up again.  The ritual 
cursing began at that point.

A buddy of mine figured the -c128 was a culprit.  It's just a tuning 
mark, but it seems to have had an effect:

> [root@fishy root]# mdadm -Cv /dev/md0 -l5 -n3 /dev/hd{e,f,g}1
> mdadm: layout defaults to left-symmetric
> mdadm: chunk size defaults to 64K

> [root@fishy root]# cat /proc/mdstat
> Personalities : [raid5]
> read_ahead 1024 sectors
> md0 : active raid5 hdg1[3] hdf1[1] hde1[0]
>       312576512 blocks level 5, 64k chunk, algorithm 2 [3/2] [UU_]
>       [>....................]  recovery =  0.1% (158808/156288256)
> finish=245.6min speed=10587K/sec

(later)

> [root@fishy root]# cat /proc/mdstat
> Personalities : [raid5]
> read_ahead 1024 sectors
> md0 : active raid5 hdg1[2] hdf1[1] hde1[0]
>       312576512 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]
> 
> unused devices: <none>

> [root@fishy root]# mkfs.ext3 /dev/md0
> mke2fs 1.32 (09-Nov-2002)
> Filesystem label=
> OS type: Linux
> Block size=4096 (log=2)
> Fragment size=4096 (log=2)
> 39075840 inodes, 78144128 blocks
> 3907206 blocks (5.00%) reserved for the super user
> First data block=0
> 2385 block groups
> 32768 blocks per group, 32768 fragments per group
> 16384 inodes per group
> Superblock backups stored on blocks:
>         32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
>         4096000, 7962624, 11239424, 20480000, 23887872, 71663616
> 
> Writing inode tables: done
> Creating journal (8192 blocks): done
> Writing superblocks and filesystem accounting information: done
> 
> This filesystem will be automatically checked every 39 mounts or
> 180 days, whichever comes first.  Use tune2fs -c or -i to override.

Another 4 hours and ten minutes or so later, and I've got a new 
filesystem.  Let's mount it, shall we?

> [root@fishy root]# mount /dev/md0 /mnt/floppy/
> mount: you must specify the filesystem type
> 
> 
> [root@fishy root]# mount /dev/md0 /mnt/floppy/ -t ext3
> mount: wrong fs type, bad option, bad superblock on /dev/md0,
>        or too many mounted file systems

> [root@fishy build]# tune2fs -l /dev/md0
> tune2fs 1.32 (09-Nov-2002)
> tune2fs: Bad magic number in super-block while trying to open /dev/md0
> Couldn't find valid filesystem superblock.

Hmm.  That's no good.

So, I'm curious, anyone out in LM land have any experience with Raid5 on 
IDE devices?  Would moving hdf to hdc be worth the perf hit?  Should the 
fact that hde and hdf are on the same cable, should that be any more 
concern than performance?  I'm not looking for lightning speed, here, 
just reliability in the face of freak environmental damage.  Anything 
else you can see in my setup/config (I'm a SWRaid newbie) that could be 
killing my array?

Also, anyone advocate the LVM-on-SWRaid method?  I'm looking to easily 
grow the size of my /home part, but if it's too risky I'll leave it out 
of the equation as I have so far.  I can copy/rebuild/copy like everyone 
else.

(Yeah, I'm a cheap bastard, and while I have a spare 29160 I don't have 
the cash for the Scsi drives, let alone a SCSI Raid card)

Thanks for your responses, and I will summarize.

  - bish
_______________________________________________
LinuxManagers mailing list - http://www.linuxmanagers.org
submissions: LinuxManagers-35TzE1X9F6582KRnZfj+bdi2O/[email protected]
subscribe/unsubscribe: http://www.linuxmanagers.org/mailman/listinfo/linuxmanagers