On Tue, 1 Feb 2011, Evan Layton wrote:
On 2/1/11 5:50 PM, Alok Aggarwal wrote:
On Tue, 1 Feb 2011, Keith Mitchell wrote:
On 02/ 1/11 04:14 PM, Alok Aggarwal wrote:
On Tue, 1 Feb 2011, Keith Mitchell wrote:
Since bootfs is a property of the pool, and not the dataset, I'm
inclined to
say it should stay the way it is. Particularly since during validation
we
bootfs is a pool property but it needs to be set to
a *dataset*.If you set it (is_root really) as an attribute of 'zpool',
then
there's no way of telling which dataset
should the bootfs property be set to. And, that seems like
a deficiency.
I think we need to keep in mind that this is not just a dataset but *must* be
a BE root dataset. Since we know the root pool and the name of the initial BE
we do indeed know the name of the BE root dataset.
Perhaps the deficiency, then, is in having a "true|false" value?
Possibly. It could be changed to have the name of the
dataset as a value but I could see that being a problem
in the example below where the user isn't laying out
custom datasets.
want to make sure there's only 1 root *pool*. Consider the slice
selection
screen of the Text Installer, wherein we need to verify that the user
has
created one and only one root pool to install into - at that stage, we
don't
even really *have* datasets.
To validate that there exists only one root pool, TI/TD
would ensure that 'is_root' is set only on a single filesystem
system wide.
The Text Installer was a bad example, as the in-DOC representation isn't
tied
to the DTD the way an AI xml manifest will be. However, suppose you have
an AI
manifest that doesn't explicitly layout any datasets, but does create
multiple
pools - how would the end user indicate which is the root pool at that
point?
That's good point. Maybe we need is_root be an attribute
of both the zpool element as well as the filesystem element.
So, if a user doesn't explicitly layout datasets but sets
is_root on a given pool, AI internally will set the is_root
attribute on the ROOT dataset.
I'm not sure why we would need to have this on both the pool and the dataset
since the name of the BE root dataset is always based on the name of the pool
and the BE name. Once you have those things you have the dataset name. I
really don't think we want to allow the user to specify a datset for this
since if it doesn't match the BE name space (for example rpool/something
instead of rpool/ROOT/be-name) nothing from beadm to pkg will work correctly.
Plus the installer uses be_init() to create the BE root dataset not something
in the installer. Keeping this a attribute of the pool and a true/false value
seems correct to me.
I wasn't aware of the bootfs property being set by
beadm. Since that's the case, TI doesn't even need
to worry about the is_root flag -- the is_root flag
in the schema can be left as is.
On a different note, I see that there exists an
'explicit_bootfs' ICT that essentially sets the bootfs
flag appropriately. Is that redundant now?
Ginnie: Will 'explicit_bootfs' ICT be ripped out as
part of your work?
Alok
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
