On Mon, Oct 18, 1999 at 12:38:22PM +0200, Jakub Jelinek wrote:
> Hi!
>
> Until now I was using non-persistant superblocks, a few days ago I changed a lot
> of small (4 disk) md devices into a few big ones with persistant
> superblocks and I must say I'm quite disappointed by totally loosing control
> over what's going on and kernel doing weird things.
> The arrays work fine until I try to remove 5 SCSI disks (on which some other
> raid existed but was commented out already from raidtab). The kernel does
> not initialize most of the arrays at all.
> Attached is /proc/scsi/scsi content, /etc/raidtab, kernel messages from the
> raidstart -a command, /proc/mdstat content and kernel messages from kernel
> shuting down the arrays from immediately before the disk removal and
> immediately after it.
> Although I can hack raid superblocks manually and change device
> numbers/recalculate checksums for now, I fear as soon as one single disk
> somewhere dies off, I won't loose just a single raid0 array, but all of
> them. And I thought persistant superblocks are there exactly so that RAID
> arrays are independent of drive shuffling.
> The kernel should try hard to find a raid superblock on some other disk now
> when this functionality went into the kernel so one cannot provide a
> translation table where which disk moved to (I have edited raidtab properly
> but raidstart does not care).
I was a bit disappointed too
I created 2 Raid 5s with 6 Disks each. I created them one after another
alwas disconnecting the other disks - Both raid 5s were created as
/dev/md1 - Afterwards i duplicated the md1 entry and created an md2
attaching all 12 Disks.
On startup the raidcode wasnt able to initialize both seperate raid5s.
It seemd it mixed up devices between the raids and started one raid
in "degraded mode" and forgot about the other completely ... When
i tried to start the other it was complaining about disks "alread in use".
Flo
--
Florian Lohoff [EMAIL PROTECTED] +49-5241-470566
... The failure can be random; however, when it does occur, it is
catastrophic and is repeatable ... Cisco Field Notice
