Dave Miner wrote:
> Frank Ludolph wrote:
>> Dave Miner wrote:
>>> Susan Sohn wrote:
>>>> The notes from today's meeting are at:
>>>> http://www.opensolaris.org/os/project/caiman/auto_install/ai_client_redesign_mtg_0520.txt
>>>>  
>>>>
>>>
>>> The concern I have is that the focus here seems to be too much on 
>>> the single-disk case, whereas the target systems for AI are highly 
>>> likely to be servers of some sort that will mostly have multiple disks.
>>>
>>> Given that, do you feel that the proposed design is really the right 
>>> one?
>>>
>> The discussion of the "single disk" case is actually what happens 
>> after a disk is selected. Given a system with multiple disks, one is 
>> (tentatively) selected and then the "single disk" considerations are 
>> applied.
>>
>
> I expect that there are requirements to do partitioning, slicing, pool 
> creation, etc., on more than one disk target.  Between that and the 
> unresolved issues in the notes about selecting a disk when there is 
> more than one, I'm concerned that it isn't quite covering the right set.

I agree multiple disk configuration should be on the table.
Given the complexity it might be introduced, I think we would
need to come with list of use cases to be supported.

In general, I assume that multiple disk configuration will be
used to create the single ZFS root pool which will be used
as target for the installation - might it be this assumption
correct or might it be other purposes for specifying and
configuring more than one disk ?

Speaking about multiple vdevs used for creating the root pool,
based on the feedback received from users so far - the most common
scenario seems to be utilizing two vdevs represented by two slices
on two separate disks to establish RAID-1 mirrored configuration.
Is it feasible to think about more than two vdevs in this use case ?

Given the fact that this is the only mirrored configuration supported
by ZFS for root pool at this point, could we consider other scenarios -
e.g. ping ZFS team what is planned and make the design open/extensible
enough to allow enhance it in easy way for supporting other configurations
if/when they become reality ?

Thank you,
Jan


Reply via email to