Based on Mary's comment, I think we can change the implementation to be mainly concerned about mountpoints rather than dataset name.

So something similar to what Ethan has suggested below will work.

- If there is a filesystem specified with mountpoint of "/var", then make sure it's located in root pool and within BE, if not fail. - If no filesystem specified with "/var" mountpoint, then create one, on root pool within BE, ensure name is default, generating one if necessary.

- If there is a filesystem specified with mountpoint of "/var/shared", ensure it's on root pool and outside BE, otherwise fail - If no filesystem specified with "/var/shared" mountpoint, then create one, on root pool outside BE, ensure name is default, generating one if necessary.

- As we are looking at mountpoints, Zvol's woll not be checked for the mountpoint checks, zvol mountpoint cannot be set at install time, and are created by default not mounted., However the zvol names do need to be checked when generating a unique name for the var and var/shared datasets.

If above makes sense I'll rework the code to do this.

cheers

Matt


Mary Ding wrote:
Dave:

S10 ZFS installation support does allow selecting an alternate dataset name. I just try this recently helping Karen to track down TI install problem with zfs. The bug submitter does have an alternate dataset name from S10U9.





On 07/ 7/11 11:53 AM, Dave Miner wrote:
On 07/ 7/11 01:47 PM, Ethan Quach wrote:


On 07/07/11 07:31, Matt Keenan wrote:
Hi,

Can I get a code review for bugs :
  7048015 Automated Installer should create a separate /var and shared
area
  7049157 Text installer should create a separate /var and shared area
  7049160 GUI installer should create a separate /var and shared area

  http://monaco.sfbay.sun.com/detail.jsf?cr=7048015


Webrev :

https://cr.opensolaris.org/action/browse/caiman/mattman/7048015.7049157.7049160



All three installers need to create /var within the installed BE and
/var/shared globally available. This is achieved by adding two
Filesystem objects to the DESIRED root Zpool object before Target
Instantiation is called. TI will then simply create them.

A new checkpoint "VarSharedDataset" is being created to handle the
additions, and will be called by all three installers.

Hi Matt,

I haven't reviewed the code yet, but wanted first to ask about the
behavior of this with AI.  Namely, in how it deals with what may or may
not already be specified in the manifest.  I would also like to illicit
input from others on how they think this should behave.

We could strictly require that the name of the datasets that are to be
used for /var and /var/share, to be the particular names we've
hardcoded.  But in thinking about it, the name of the dataset is
somewhat irrelevant; what really matters is the dataset's "in_be" status
and it's mountpoint.  As long as the user specified something that
results in having those met, things "should" still be ok. For example,
if what they specified results in the following:

      rpool/ROOT/solaris            "/"
      rpool/ROOT/solaris/foo        "/var"
      rpool/export                  "/export"
      rpool/export/home             "/export/home"
      rpool/blah                    "/var/share"


this could actually be acceptable.  Nothing downstream (beadm, pkg, or
the OS) relies on the dataset name coinciding with the mountpoint.

If we were to go this route, then for cases where the user has used up
the preferred dataset names for other purposes, we could perhaps just
generate some other random dataset names and set the right mountpoints.
For example, if what they've specified is:

      rpool/ROOT/solaris            "/"
      rpool/ROOT/solaris/var        "/foo"
      rpool/export                  "/export"
      rpool/export/home             "/export/home"
      rpool/VARSHARE                "/blah"


we could really just pick some other dataset names and make sure we have
an in_be /var, and an shared /var/share.  i.e. would could add in:

      rpool/ROOT/solaris               "/"
      rpool/ROOT/solaris/var           "/foo"
      rpool/ROOT/solaris/var_<random>    "/var"
      rpool/export                     "/export"
      rpool/export/home                "/export/home"
      rpool/VARSHARE                   "/blah"
      rpool/VARSHARE_<random>            "/var/share"



And I suppose the failure cases would be where they specified any
dataset that is not in_be that has a mountpoint "/var", or if they
specified any dataset that is in_be, but has a mountpoint of
"/var/share", then we fail.


What do people think, do we need to be this flexible in AI?


I agree that we could be, but I'm not sure we need to be. Did S10 ZFS installation support allowed selecting an alternate dataset name? I don't believe so, though I haven't verified. If it did, then that might argue that we should here. If not, are there any RFE's requesting it?

Dave
_______________________________________________
caiman-discuss mailing list
caiman-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss

_______________________________________________
caiman-discuss mailing list
caiman-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss

_______________________________________________
caiman-discuss mailing list
caiman-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss

Reply via email to