John Plocher wrote:
> Lori Alt wrote:
>> I'm not surprised that having /usr in a separate pool failed.
>> The design of zfs boot largely assumes that root, /usr, and
>> /var are all on the same pool, and it is unlikely that we would
>> do the work to support any other configuration any time soon.
>
>
> This seems, uhm, undesirable. I could understand if the initial
> *implementation* chose to make these simplifying assumptions, but
> if the *architecture* or *design* of the feature requires this,
> then, IMO, this project needs a TCR to not be done that way.
It's not inherent in the design of zfs boot. It's more a matter
of the current implementation. For example, install and liveupgrade
(and future boot-environment management tools) will get a fair
amount of mileage from the fact that you can set a mount point
at the top of a boot-environment dataset hierarchy and all of
the subordinate file systems in the boot environment will inherit it.
That kind of thing will only work if the file system composing
the BE are in the same pool.
In the initial release, the early SMF scripts that mount root, /usr,
var, etc.
assume that they are in a well-defined hierarchy:
<pool>/<be-name>
<pool>/<be-name>/usr
<pool>/<be-name>/var
such that once the <pool>/<be-name> is known, all of the other
file systems can be found relative to it. This only works if they
are in the same dataset.
>
> Certainly, many of us will be satisfied with all-in-one pool,
> just as we are today with all all-in-one filesystem, so this
> makes sense as a first step. But, there needs to be the
> presumption that the next steps towards multiple pool support
> are possible without having to re-architect or re-design the
> whole zfs boot system.
>
No, re-architecting should not be necessary.
Lori
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
