All,
I appreciate the amount of play my "newbie" question has
had, and have the feeling we are teetering an inch from an
answer. I've got to leap that inch - the infuriating
alternative is that our whole Linux-RAID development gets
tossed and replaced with antediluvian hardware RAID at
tremendous, absurd cost.
There's got to be a way around this!!! I SIMPLY CANNOT
BELIEVE that competent designers didn't come up with a failover
path when that is the whole point of RAID (that it can run in
degraded mode till the new hardware comes on line). Having it
try to rebuild when it has just LOST a disk is nothing more
than a flag bug - surely fixed somewhere??? That's what seems
to lead to the uninterruptible sleep.
raidhotremove seems to THINK it can work without unmounting
the raid array fs... same with the echo to /proc/scsi/scsi ...
it's really all just syncing code, isn't it, guys?
At 01:25 AM 9/16/99 +0100, Paul Jakma wrote:
>On Tue, 14 Sep 1999, Lawrence Dickson wrote:
>
> So I take it the 18 disk RAID has to be unmounted before I
> can do this. That's a killer.
>
>eek, i was tired.. i didn't mean to say raidstop - sorry. The array
>doesn't need to be stopped if it's a fault tolerant array. So should
>be:
>
>The *disk to be swapped* must be *taken out of the array* - ie
>raidhotremove. Then raidhotadd the new disk in.
All makes logical sense if it weren't for those D's in the
ps ax output.
>
> We have proper hot-swap hardware but that does not help when
> the scsi driver forces us into uninterruptible sleep.
>
>Some drivers are better than others at handling errors. But the linux
>scsi layer holds a lot back. I think it's due a revamp for 2.5.
But maybe it's just this attempt to rebuild onto a missing disk.
>
> Thanks,
> Larry
>
>
>regards,
>--
>Paul Jakma
>[EMAIL PROTECTED] http://hibernia.clubi.ie
>PGP5 key: http://www.clubi.ie/jakma/publickey.txt
>-------------------------------------------
>Fortune:
>The only "intuitive" interface is the nipple. After that, it's all learned.
>(Bruce Ediger, [EMAIL PROTECTED], in comp.os.linux.misc, on X interfaces.)
>
