ZFS Why are /usr and /var not in a boot environment?

STREBLO

STREBLO

By default the file system structure was set up as is set up so that /usr and /var are not inside a boot environment dataset and have canmount set to off.

Code: 
$ zfs list -H -o name,mountpoint,canmount
NAME             MOUNTPOINT  CANMOUNT
s${ZROOT}/ROOT      none    on
${ZROOT}/ROOT/default      /       noauto
${ZROOT}/tmp       /tmp    on
${ZROOT}/usr       /usr    off
${ZROOT}/usr/home  /usr/home       on
${ZROOT}/usr/ports /usr/ports      on
${ZROOT}/usr/src   /usr/src        on
${ZROOT}/var       /var    off
${ZROOT}/var/audit /var/audit      on
${ZROOT}/var/crash /var/crash      on
${ZROOT}/var/log   /var/log        on
${ZROOT}/var/mail  /var/mail       on
${ZROOT}/var/tmp   /var/tmp        on

I can see that this is set up so that data falls through into the root dataset and is not saved inside /usr and /var. What doesn't make sense to me is why are /usr and /var in that case not just mounted in the default boot environment?

Like this:

Code: 
NAME                                       MOUNTPOINT  CANMOUNT
${ZROOT}/ROOT                              none                   on
${ZROOT}/ROOT/default                  /                          noauto
${ZROOT}/ROOT/default/usr            /usr                     on
${ZROOT}/ROOT/default/var            /var                     on
${ZROOT}/tmp                                  /tmp                    on
${ZROOT}/usr                                   none                   off
${ZROOT}/usr/home                         /usr/home           on
${ZROOT}/usr/ports                          /usr/ports            on
${ZROOT}/usr/src                             /usr/src                on
${ZROOT}/var                                   none                    off
${ZROOT}/var/audit                          /var/audit             on
${ZROOT}/var/crash                         /var/crash            on
${ZROOT}/var/log                             /var/log                on
${ZROOT}/mail                                 /var/mail               on
${ZROOT}/tmp                                  /var/tmp               on


It would seem to me that that would result in the same conclusion of whatever being put in user and var ending up in the default boot environment. Is it just not necessary to add the additional data sets?
 
The "mountpoint" property for zroot/usr and zroot/var is set so that their children can inherit it. Simple as that.
 
ANOKNUSA said:
The "mountpoint" property for zroot/usr and zroot/var is set so that their children can inherit it. Simple as that.
Click to expand...

I know the datasets are created so that they can be inherited from, what I'm saying is would it make sense to create actual datasets in the main root data set and actually mount them? Are they not created just for simplicity's sake?

Right now by default they are set to not be mounted so all data goes into the default dataset. Creating actual datasets ${ZROOT}/ROOT/default/var, ${ZROOT}/ROOT/default/usr and actually mounting them would result in the same thing right?
 
I think it's just to make the pool/ROOT/foo the sufficient level at which to snapshot and clone for beadm. Otherwise there would need to be additional logic to track the children filesystems. It's also much easier for the boot loader to only have to mount one thing (if you select a different BE) and not recurse through a tree.
 
Eric A. Borisch said:
I think it's just to make the pool/ROOT/foo the sufficient level at which to snapshot and clone for beadm. Otherwise there would need to be additional logic to track the children filesystems. It's also much easier for the boot loader to only have to mount one thing (if you select a different BE) and not recurse through a tree.
Click to expand...
So we COULD have both ${ZROOT}/ROOT/default/usr mounted to segment data, and for clearness and inheritance keep ${ZROOT}/usr, but leave it canmount=off?
 
When using UFS, we usually partition the drive into

Code: 
/
/usr/local/
/usr/src/
/usr/obj/
/usr/ports/
...

Notice that there is no separate partition for /usr. So that / contains a working OS. There are two ways to emulate this behaviour in BE. Either create each dataset and set the mountpoint to say, /usr/local or create a dataset /usr but do not mount it and then create descendents with it.
 
So can I not create and mount ${ZROOT}/ROOT/default/usr and ${ZROOT}/ROOT/default/var? Will they break something?
 
STREBLO said:
So can I not create and mount ${ZROOT}/ROOT/default/usr and ${ZROOT}/ROOT/default/var? Will they break something?
Click to expand...

You certainly can, but it won't match beadm's assumptions. Your /usr and /var are tightly linked to your OS install.

If you aren't using BEs, just set system/usr and var to canmount=on (but transfer the data via a temporary mount first.) Yes, you could make them under ROOT/default with mountpoints of /usr and /var, but with what benefit?
 
Makes it easier to move data around, as well as snapshot and backup if they are in smaller data sets. But yes I do plan to use BEs.
 
t1066 said:
Notice that there is no separate partition for /usr. So that / contains a working OS.
Click to expand...
Just to add to this: it's not uncommon to place /usr on a different slice. It's also the main reason why /rescue exists and why it's considered bad practice to change the root shell with a 3rd party one (although that also involves /usr/local).

But basically you can have a working OS without /usr. Granted, it wouldn't provide too much extra's (no e-mail, no utilities such as telnet, etc.) but it will boot your system and provide a basis to work with (usually system diagnostics or from there mount the rest).
 
STREBLO said:
I know the datasets are created so that they can be inherited from, what I'm saying is would it make sense to create actual datasets in the main root data set and actually mount them? Are they not created just for simplicity's sake?
Click to expand...

You misunderstand. The datasets under zroot/usr and zroot/var are deliberately created so they are not in boot environments. They're things like application logs and mail spools that you don't want reverted when you change boot environments or restore a backup. By creating those two datasets you can create child datasets that inherit the "mountpoint" property so it doesn't have to be set manually for each one.
 
No, I understand that completely. I wasn't talking about the datasets under usr and var I was talking about the data sets themselves.
 
STREBLO said:
No, I understand that completely. I wasn't talking about the datasets under usr and var I was talking about the data sets themselves.
Click to expand...

If you mount the /usr and /var datasets as they are now, all of the contents of those two directories would get excluded from the boot environment. You don't want that. You'll inevitably break something, as successive updates to the the binaries and libraries in /usr and the records kept in /var would cause the contents of those datasets to diverge from the contents of older boot environments. If a bad update required you to boot into an older boot environment, you might find that boot environment to be just as broken as the most recent state of the system.

If you create those dataset trees within the boot environment hierarchy---zroot/ROOT/default/usr, for example---everything will be included in the boot environment. You don't want that either, because that will result in data you don't want touched when changing boot environments getting touched when you change boot environments, and would also end up replicating and indefinitely storing a whole bunch of data that you don't really need or want hanging around. (Do you really want a half-dozen copies of log files, outdated ports trees and outdated package caches hanging around your disk for no reason?)

You're thinking in all-or-nothing terms, but the whole concept of "boot environments" is that ZFS allows you more fine-grained control over the important parts of the system when making changes. It's what makes the difference between a "boot environment" and a regular old partition backup. It's like difference between using a revision control system when you modify one file in a directory, versus just making a complete copy of the whole directory when you modify the file.

EDIT: Cleaned up my explanation a bit.
 
You must log in or register to reply here.
Back
Top