Jan,
On 05/25/12 12:35, Jan Damborsky wrote:
On 05/24/12 07:01 PM, Matt Keenan wrote:
On 05/24/12 16:24, Jack Schwartz wrote:
Hi Matt.
I'm sure the fix works as you've tested it in our environment, but I
want to understand better the reason under the fix.
It looks to me that there is a race condition between setting something
up (happens to be a user account) under rpool/export and mounting the
rpool/export zfs filesystem tree. The fix appears to be to specify the
mountpoint to zfs only when the default mountpoint doesn't match the
fs.mountpoint.
There is definitely a difference between the sequence of events that
take place on initial boot depending on whether users are created
automatically via profiles or manually via sysconfig.
As far as process of manipulating home ZFS dataset
is concerned, there is no difference between those two sysconfig
scenarios (non-interactive versus interactive).
That said, I did notice an issue in interactive scenario which
seems to get triggered by this bug. In particular, sysconfig UI doesn't
allow to create initial user account, since it thinks that parent
of to-be-created home ZFS dataset does not exist - I filed 7171775
for this.
Yeah just read that bug report, of course the reason rpool/export/home
dataset had an extra "/" at end was because in b16 the mountpoint was
being manually set to what target discovery determined to be the default
mountpoint e.g. /export/home/
This bug fix is trying to ensure this does not happen going forward.
Why, I don't know.
Users's home dirs are created as datasets under rpool/export/home
If rpool/export/home has it's mountpoint manually set to
rpool/export/home the automatic user creation succeeds, but the home
directory is created before rpool/export/home dataset is mounted.
If the mountpoint for rpool/export/home is left at "inherited" this
sequence works.
Someone else more knowledgeable can probably explain this better. My
fix just reverts back to what has been happening all along and ensure
things continue to work.
Let me try to explain. In general, when dataset with mountpoint inherited
from its parent is mounted,ZFS automatically mounts its parent as well.
In our particular case, when svc-config-user creates and mounts ZFS home
dataset,
(in order to copy necessary config files there), ZFS also automatically
mounts all its ancestors, since home ZFS datasets is created with
mountpoint
inherited from rpool/export/home which in turn is created with mountpoint
inherited from rpool/export.
'zfs mount -a' later called from filesystem/local recognizes those datasets
are already mounted and skips them.
The reason filesystem/local started to fail is that since
rpool/export/home doesn't
inherit mountpoint from rpool/export, rpool/export dataset is not mounted
when ZFS home dataset is created. Then later filesystem/local gives up
when trying
to mount that dataset, since 'zfs -a mount' can't mount ZFS dataset
which has children
already mounted.
Thanks for the explanation, certainly makes sense to me now.
regards
Matt
Hope this clarifies things a bit,
Jan
1) What would the default mountpoint and fs.mountpoint be in the case
when setting up a user?
The code is not concerned directly with creating a user. Initial user
creation is done as stated either automatically via sysconfig profiles
or manually on first boot, so mountpoint vs fs.mountpoint is not
relevant here.
2) How come not specifying mountpoints fixes a race condition? The term
"ZFS inheriting from its parent" to me still means a new ZFS file system
will be created. (How could there be a parent if there was no child
created?) Does the new ZFS file system get created at a different point
in time?
To be honest as stated I'm not really sure why it fixes the problem.
In terms of rpool/export/home, a new dataset is created and it does
have a parent rpool/export.
cheers
Matt
Thanks,
Jack
On 05/24/12 04:09 AM, Matt Keenan wrote:
Hi,
Can I get a pair of eyes on a fix for bug :
Bug;
7171068 booting zones with non-root users in SC config profiles leads
to svc:/filesystem/local in mainteance
http://monaco.us.oracle.com/detail.jsf?cr=7171068
Webrev:
https://cr.opensolaris.org/action/browse/caiman/mattman/7171068/
Bug is caused by fix for 7166325, which attempted to fix where
mountpoints even if specified in Manifest were ignored during zones
creation.
What was not realized during this fix is that Target Discovery will in
99% of cases always set the mountpoint property of a filesystem during
discovery, regardless of whether it's specified in the manifest or not.
Because of this after fix for 7166325, ALL datasets being created in a
zone were now explicit setting their mountpoint. This should not be
the case, in particular rpool/export/home needs to inherit it's
mountpoint from it's parent. Mountpoint setting should only happen
where the mountpoint differs from the default mountpoint as set by
Target Discovery. Target Discovery sets the mountpoint because DC
needs to know this.
- Tested installing zones where users are autoconfigured.
- Also ensured bug 7166325 is fixed with this new revision.
- Ran full suite of unit tests and no regressions found.
regards
Matt
_______________________________________________
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
