Ethan Quach wrote:
>
>
> Kyle McDonald wrote:
>> This sounds interesting. Though it makes me ask: Why then does it
>> need to be mounted in /var/share/ at all?
>> Why not mount it where it belongs...
>>
>> For example, if a ZFS filesystem <pool>/SHARE/mail is created, why
>> can't the ZFS property 'mountpoint' be set to /var/spool/mail?
>> Why set it to /var/share/mail, and then make a softlink named
>> /var/spool/mail?
>
> Under this proposal the existence of /var/share is to indicate to the
> BE system what
> directories need to be shared, and hence separate datasets.
>
Sounds to me like that is meta-data that might be better implemented as
a ZFS property. 'sharedfs' maybe.
It could be used for all shared filesystems (in a root pool - I'd expect
all FS's in a non-root pool to be shared automatically) for that
matter... /export, /export/home,...
Actually, maybe it's the not-shared FS's that need a 'not-shared' property??
>>
>> Also right now ZFS creates the directory a filesystem is to be
>> mounted on automatically. How will this 'mount only if mountpoint
>> exists' function be implemented?
>
> Theres a new value for the zfs canmount property called 'noauto',
> which those
> under <pool>/SHARE would be set with. Datasets set with this won't
> automatically be mounted at boot up, and would get processed specially.
>
If the shared FS's were mounted directly where they normally live, I'm
not sure they'd need to be 'noauto' and if they'd need any special handling.
>> Will the special behaivor apply to all things in <pool>/SHARE? or
>> will there be some other ZFS property ("conditionmount"?) that
>> triggers this behavior?
>>
>> If the former, what happens if someone happens to make a ZFS named
>> <pool>/SHARE/foo on their own?
>> If the latter, why force them into <pool>/SHARE/ at all?
>
> The idea was to make <pool>/SHARE a special area, so if someone makes a
> dataset under there on their own, it'd get processed the same way at
> boot.
>
It still may be nice to keep these in <pool>/SHARE in root-pools, but
with a per-FS attribute (either 'shared' or 'not-shared') do they need
to be segregated?
>>
>> Other questions I've been meaning to ask about the interaction
>> between ZFS and SnapUpgrades and BE's:
>>
>> Can there be a ZFS pool for each BE? Or only one pool?
>> Can there be more than One BE in the same pool? or only one BE per pool?
>
> There certainly can be more than one BE in the same pool. The benefit of
> cloning a BE is based on this.
But multiple root-pools are also allowed, correct?
>>
>> Assuming that both of those are allowed... can a BE have FS's in more
>> than one pool?
>
> FS's in another pool must be shared FS's, like <pool2>/export5
> A BE's system file systems, i.e. file systems which get cloned when
> the BE is
> cloned, must all reside hierarchically underneath its root dataset in
> the same
> pool.
Ok.
It seems to me that it might make sense to make a requirement that there
be only one active rootpool at a time, and that all OS FS's that are
shared (these dirs we're talkinga bout mounting in /var/share) need to
be in that rootpool. All other FS's in other root-pools would be ignored
(by default) and other FS's in non-rootpools would be 'shared' by
default and treated like they are today.
>
>>
>> When there are more than one pool, what happens if there are more
>> than one <pool>/SHARE/...??
>
> We'd have to come up with some way to deal with this. Perhaps the BE
> that's
> booting up prefers the one that's in the pool it lives in and ignores
> others.
>
That kind of goes with what I was saying above.
Actually makes me wonder when you'd want a BE in a totally separate
rootpool, vs when to use the same root pool?
It seems that cloning for patching, upgrades, etc would be new BE's in
the same pool (to take adavantage of snapshots.) But when to use a new
pool? I suppose scratch installing a new BE might be one case, but I
can't see why you'd *need* a new pool for that - you may want one, but
I'm not sure why...
-Kyle
