On 06/22/10 12:20, Keith Mitchell wrote:
On 06/22/10 12:10 PM, Ethan Quach wrote:
On 06/22/10 11:50, Keith Mitchell wrote:
On 06/22/10 08:53 AM, Matt Keenan wrote:
On 06/22/10 04:42 PM, Dave Miner wrote:
On 06/22/10 11:36 AM, Matt Keenan wrote:
Dave,
Thanks for the review :
On 06/15/10 05:06 PM, Dave Miner wrote:
Overall a pretty complete spec. A few items:
3.2.1.1 - Section could use some reformatting, as there are bullets
shown as parallel that are actually sub-bullets of a previous one.
Consider using some numbering here, maybe.
Yep, noticed this after I had sent out document, corrected now.
3.2.2.1 - What impact does this have on validation of the new
elements
introduced here?
Xmllint will do the required relaxng syntax checking, any other
validation required will be done within auto_install client code
itself,
manually.
Do you think I should be adding validation values in here ? as
according
to Ethan this file is being obsoleted, and I'd like to limit the
amount
of throw away code written.
No, I don't, just wanted to understand the impact.
3.2.2.4 (last bullet on page 15) - This phrasing is confusing:
"Pool
name does not exist. If pool name is specified in manifest,
then this
pool will be overwritten." I'm not sure what to expect - will an
existing, named pool be overwritten automatically?
Yes, if the the manifest contains a user specified pool name of
"my_new_pool", and this pool already exists on the target being
installed to then this pool will be overwritten.
That seems... dangerous. Wouldn't it be better to require a
specific directive to overwrite an existing pool?
Ethan and myself discussed this very issue, and came to the
conclusion that if the user specifically states the pool name they
inherently realize that this pool is going to be destroyed as we
only support the "create" action for "zpool" elements.
Future development iterations could allow for "preserve" actions
for "zpool" elements which would cater for this.
I would normally error on the cautious side and not destroy
existing layouts, however as it is a create action I think this may
be the correct approach. I'm open to persuasion though.
Why would an existing pool need to be destroyed, if it's on a
separate, untouched disk? It's completely possible to have two data
pools with the same name. They just can't both be imported
simultaneously under the same name.
I think the statement is only meant to apply when its the same the
underlying device. I'd agree this bullet could probably use some
clarification.
If the underlying disk is the same, for the data pool(s), there should
be no need to delete. e.g. if cXdXp2 has a pool named "data", p1 is
the new rpool target, and p3 is selected to have a pool named "data",
the pool on p2 should not need to be destroyed).
I don't think we're trying to say different things. Notice I said
underlying
device not underlying disk.
But I should have clarified that my usage of the term 'device' was meant
to be in accordance to how zpool(1M) uses it.
However, for the root pool, naming conflicts could confuse the boot
process.
I think a bug was fixed so that when booting with findroot() and
a pool name is given but multiple pools exist on that system with
that name, Grub will choose the current device from which it read
the menu.lst, so I think its not a problem anymore.
thanks,
-ethan
(Side question: can two pools with the same name really be
simultaneously
import now? That wasn't the case before. Does zpool auto-adjust the
second imported pool to a temporary subname or something?)
No, as stated, they can't both be imported. They can both exist on
disk, but in order to have access to both simultaneously, at least one
of them would need to be manually imported under a different name.
However, it's also possible to import one, use it, export it, import
the other, use it, etc., without ever changing the pool name.
- Keith
-ethan
- Keith
Matt
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
