Re: pinning down dk? assignment

[mlelstv%serpens.de@localhost (Michael van Elst)]

christos%astron.com@localhost (Christos Zoulas) writes:

>In article <juk971$qpi$1%serpens.de@localhost>,
>Michael van Elst <mlelstv%serpens.de@localhost> wrote:
>>ef%math.uni-bonn.de@localhost (=?iso-8859-1?Q?Edgar_Fu=DF?=) writes:
>>
>>>> It probably won't help you with raidframe.
>>>It would indeed help in my case. In case sd6 has gone missing, so dk4
>>is on the RAID and not on sd6, it would prevent the wrong filesystem
>>being mounted for dk5.
>>
>>I was refering to the situation with building a raid on wedge components.
>>Wedges on top of raid are no problem.

>Actually I do exactly that (raid on top of wedges)

>dk0 at wd0: wd0a
>dk0: 488397105 blocks at 63, type: raidframe
>dk1 at wd1: wd1a
>dk1: 488397105 blocks at 63, type: raidframe
>dk2 at sd0: sd0a
>dk2: 117210177 blocks at 63, type: ffs
>Component on: dk0: 488397105
>Component on: dk1: 488397105
>Found: dk1 at 0
>Found: dk1 at 0
>Found(low mod_counter): dk0 at 1
>raid0: Components: /dev/dk1 /dev/dk0[**FAILED**]


Let wd1 disappear and the raid will try to use wd0a (dk0) and sd0a (dk1).
Of course raidframe will notice the mismatch in this case, but you can
easily imagine more complex scenarios where it doesn't. But a simple
failure case comes from trying to recover the failed wd1 without
rebooting. When you replace the drive it may attach as wd1 but then
as dk2. Now try to teach raidrame that its component changed the path.

-- 
-- 
                                Michael van Elst
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."