> > <br> > >> I am trying to understand this better. > In the case you > describe <br> > >> above, in JS, a disk that met a certain > criteria would > be used<br> > >> to mirror. How would simply aliasing disks > to disk0 and > disk1<br> > >> achieve this ?<br> > > </span><br> > hat simple case wouldn't - Unless you knew that the > machines this<br> > manifest applied to both had at least 2 disks and > that they were<br> > compatible, but the device names arne't always > the same.<br> <br> <br>
It sounds like the way AI creates the pool may potentially be part of the problem. <br> <br> If the pool is created as a mirror right from the beginning then the pool size will be the smaller of the two, and so compatibility requirements are pretty liberal. If the pool is initially created as non-mirrored, consisting of only the single 'boot_disk' device and then the second (mirror) device is attached then it has to be at least as big as the boot_disk. <br> <br> So how does the mirror get created by AI? Does it create the pool in one single pass, including the mirror specification, or attach the mirror after creation of an initial, non-redundant pool? <br> <br> Either method will have it's own respective set of unpredictable side-effects on resulting pool size or flexibility however. <br> <br> > <br> > What is more useful for mirroring root is if AI > could have logic > to<br> > pick a disk that is 'compatible' with 'boot_disk' > and allow you to<br> > reference it through 'boot_mirror'.<br> > <br> > In addition (whether 'boot_mirror' is possible or > not) having > symbolic<br> > names for 'disk0' through 'diskN' would also be > useful in many > cases.<br> -- This message posted from opensolaris.org _______________________________________________ caiman-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
