Solved Questions re beadm

M

mefizto

Greetings all,

as the subject line indicates, I need some help with confirming my (mis)understanding of beadm(1).

1. I understand that a new boot environment is cloned from all the data-sets under the rpool/ROOT, while the shared datasets that contain the same mount point in both the active and inactive boot environments, i.e. rpool/, are not cloned, and the new boot environment accesses the original, shared data-sets.

2. If the above is correct, the question arises – what data-sets to include in the boot environment? From my search I have found the answer to be “it depends”, which is perfect answer to experienced users, but not quite satisfactory for the rest of us. So, I though that all the system dependent data-sets should be in the cloned boot environment. However, it seems that different people have different opinion on the definition of the system dependent term. Furthermore, if one includes the /, /usr, and /var will all the child data-sets be automatically included?

Any input would be greatly appreciated. My main interest is to create a cloned boot environment for safe updates/upgrades/changes to the operating system.

3. Assuming that 1 is correct and 2 can somehow be solved, is there a way to set-up the data-set organization before installing the operating system? Or is the solution to use zfs rename to move the data-sets?

Kindest regards,

M
 
The way I have my ZFS-on-root system setup at home is:

pool/ROOT is just a placeholder ZFS dataset, with mountpoint=none set.
pool/ROOT/default is the default root filesystem for my server, mounted as / with all the boot goodness enabled.
pool/home is mounted on /home and there are separate datasets for various things underneath that.
pool/tmp is mounted on /tmp with a reservation of 6 GB (mostly so I can burn DVDs without running out of room).
pool/usr is just a placeholder ZFS dataset, with mountpoint=none set.pool/usr/local is mounted on /usr/local
pool/usr/ports is mounted on /usr/ports
pool/usr/obj is mounted on /usr/obj
pool/usr/src is mounted on /usr/src

This way, the BE includes the complete base OS (/ /var /usr) but doesn't include /home, /usr/local, /usr/ports, /usr/src, or /usr/obj. Those last two should probably be included in the BE if you do lots of from-source builds, as you want the sources to match the OS in use.

pool/ROOT and pool/usr are only used to set default configuration options that get inherited by all the child datasets below, and to provide a nicely organised zfs list output. :)

To me, the way FreeBSD logically separates things between "base OS", "installed ports", and "user files" really suits ZFS setups. Only the data under pool/ROOT/<be-name> is included when creating new BEs.

As for your question 3, you need to drop to a shell during the install, and do all the ZFS setup manually, and get all the filesystems mounted into the right locations, then exit the shell to continue the install using the layout you created. At least, that was the method required in FreeBSD 9.x, the last time I installed a ZFS-on-root system from scratch. :) The installer may be smart enough to do this automatically now.
 
Hi phoenix,

thank you very much for your reply. I still have some difficulty with the concept. Could you please review the following data-set layout and reasoning, and if you feel like, add explanation for my benefit?

The following data-set, I am quite certain about:
rpool/ROOT mounted on none just as you suggested, for setting default configuration options.
rpool/ROOT/default mounted on /, ditto. Could you explain your term "all the boot goodness"?
rpool/ROOT/usr/obj mounted on /usr/obj; I do use synth.
rpool/ROOT/usr/src mounted on /usr/src, ditto.

Installed ports, should be independent of the boot environment.
rpool/usr/ports mounted on /usr/ports.

This probably does not matter since /tmp is cleared at shutdown. At the same time, I do not see why it shoud be in the boot environment.
rpool/tmp mounted on /tmp.

User data, should be independent of the boot environment.
rpool/home mounted on /home.

The following var data-sets might change and should such be preserved in potential return to older boot environment

Code: 
rpool/var        none
rpool/var/crash  /var/crash
rpool/var/log    /var/log
rpool/var/mail   /var/mail
rpool/var/tmp    /var/tmp
rpool/var/db/mysql   /var/db/mysql

You wrote:
"This way, the BE includes the complete base OS (/ /var /usr) but doesn't include /home, /usr/local, /usr/ports, /usr/src, or /usr/obj. If this is correct, should not the:

rpool/usr mounted on none be rpool/ROOT/usr mounted on none?
rpool/var mounted on none be rpool/ROOT/var mounted on none?

I am not sure about the following data-sets:
Should the /usr/local be part of boot environment or not?

As I understand by your comment to my question 3, when the installer starts, I will select the shell and manually enter the selected data-set organization. Then I resume the installation. Do I just continue with the installation or do I need to do some additional management to retain the organization?

Kindest regards,

M
 
mefizto said:
rpool/usr mounted on none be rpool/ROOT/usr mounted on none?
rpool/var mounted on none be rpool/ROOT/var mounted on none?

I am not sure about the following data-sets:
Should the /usr/local be part of boot environment or not?
Click to expand...

Everything that's in rpool/ROOT is part of a boot environment. Some things in /var or /usr should be in a boot environment, but not everything. Say you changed rpool/var/db/mysql to rpool/ROOT/var/db/mysql. If you then switched from one boot environment to another boot environment later, everything recorded in your MySQL database in the time between when the two boot environments were created would be lost.
 
The 11.0 installer, if you select root on ZFS, will by default give you a beadm-ready layout, so I would suggest starting there. You can always tweak it after the fact if you really don't like something, but it is a good starting point.

It will be the "standard" (as in the one I typically see described) beadm layout with zroot/usr and zroot/var set to canmount=off and mountpoint=/usr and /var, respectively, such that the descendant FS can inherit the mountpoint, but other directories created under /usr and /var (i.e. any that aren't separate ZFS filesystems) are part of the BE.
 
mefizto said:
as the subject line indicates, I need some help with confirming my (mis)understanding of beadm(1).
Click to expand...
It is a detail, but try to get the syntax of that link right. Being unfamiliar with the program I tried following the link and it doesn't work. A port is always denoted by its main "category" or directory under /usr/ports followed by the name. So: [port]sysutils/beadm[/port] resulting in sysutils/beadm.

Or you can refer to the manualpage, which you tried to do: [man=1]beadm[/man]. This would result in beadm(1).

You'll notice that these links do work and that can be quite helpful for someone else to read up on what is being discussed. Figured I'd share.

Can't help here because I always set up my ZFS installations manually. I dislike all the unused file systems and actually consider it a bit of a clutter. On my systems zroot is the main pool which is mounted under / and also contains /usr (but not others such as /var, /usr/local and /usr/ports).
 
Greetings all,

first, thank you very much for your time trying to help. Based on my comments below the two remaining issues are:
1. which child data-sets should be excluded from the boot environment; and
2. how to deal with the installation process.

Hi ANOKNUSA,

You wrote: "Everything that's in rpool/ROOT is part of a boot environment. Some things in /var or /usr should be in a boot environment, but not everything."

Yes, I understand this. The purpose of my question was to (1) understand why /var and /usr should not be under rpool/ROOT/usr respective rpool/ROOT/var, since they are part of boot environment, instead of the rpool/usr respective rpool/var as phoenix suggested, and (2) which child data-sets should be excluded from the boot environment.

Regarding (1), I now understand that the /var and /usr are mounted as rpool/usr respective rpool/var with a
Code: 
canmount=off
, which supposedly causes all the child data-sets to be part of the boot environment unless expressly excluded.

Regarding (2), I am still not certain, whether I have identified all the data-sets that should not be in the boot environment, e.g., the /usr/local.

Hi Eric A. Borisch,

I actually started with the default layout, but I have made some changes, I could not find some data-sets in the changed boot environment. Hence my question.

I do understand that I can change the organization post installation, but the consensus appears to be to start with the preferred organization.

Hi ShelLuser,

thank you for the explanation of the tags, I had difficulty to figure it out.

Kindest regards,

M
 
So I'll put it this way now: imagine if every time you rebooted your computer, a backup got restored and erased everything you had done since the time you made that backup. That's what happens when you switch boot environments. If there's anything you wouldn't want deleted when you restore a backup, don't put it in a boot environment.

That would include applications you've upgraded, configuration files for new applications you've installed, user data, the package database, an up-to-date ports tree, and anything else you can think of that you don't want changed.

Everything that you need for a clean, working system should go into the boot environment. That's usually just the things that are on the disk after you install a brand new system: no logs, no packages, no mail, no temporary files, no ports tree---only the things necessary for the operating system to run properly.

If you ask me, it's rather stupid that the installer names the datasets after the directory trees where they're mounted. That just makes dataset trees and mountpoints blur together, and then people keep trying to explain boot environments using those default examples from the installer. I name all my dataset trees after what they're for rather than where they're mounted, so maybe my setup will help:

Code: 
tank                       none
tank/ROOT                  none
tank/ROOT/11.0-RELEASE-p9  /
tank/ROOT/master           /
tank/apps                  /usr/local
tank/apps/config           /usr/local/etc
tank/apps/pkgcache         /var/cache/pkg
tank/apps/pkgdb            /var/db/pkg
tank/apps/portstree        /usr/ports
tank/build                 none
tank/build/obj             /usr/obj
tank/build/src             /usr/src
tank/data                  /usr/home/anoknusa
tank/data/design           /usr/home/anoknusa/design
tank/data/dotfiles         /usr/home/anoknusa/.local/dotfiles
tank/data/edit             /usr/home/anoknusa/edit
tank/data/mail             /usr/home/anoknusa/.local/var/mail
tank/data/organize         /usr/home/anoknusa/organize
tank/data/write            /usr/home/anoknusa/write
tank/media                 none
tank/media/comics          /usr/home/anoknusa/read/comics
tank/media/ebooks          /usr/home/anoknusa/read/ebooks
tank/media/music           /usr/home/anoknusa/listen/music
tank/media/spokenword      /usr/home/anoknusa/listen/spokenword
tank/media/standup         /usr/home/anoknusa/listen/standup
tank/variable              none
tank/variable/crash        /var/crash
tank/variable/log          /var/log
tank/variable/mail         /var/mail
tank/variable/tmp          /var/tmp
 
Hi ANOKNUSA,

the first paragraph of your reply is brilliant, that makes perfect sense.

As I have been reading about the beadm(1), I noticed that many people do rename the data-sets, without any explanation.

Finally, thank you for posting your organization. Regarding that, why to you mount some of the data-sets as none instead of canmount=off? From what I understand, the difference is, that none does not have mount-point property. Since you are mounting the /usr/obj respective /usr/src on tank/build, would it not be advantageous that they inherit the mount-point property of the tank/build? Or am I still missing an important concept?

How do you deal with the data-set layout and installation?

Kindest regards,

M
 
mefizto said:
Finally, thank you for posting your organization. Regarding that, why to you mount some of the data-sets as none instead of canmount=off? From what I understand, the difference is, that none does not have mount-point property. Since you are mounting the /usr/obj respective /usr/src on tank/build, would it not be advantageous that they inherit the mount-point property of the tank/build? Or am I still missing an important concept?
Click to expand...

I'm not convinced that the benefit of assigning mountpoints to filesystems that are never intended to be mounted, so that child datasets inherit the parent's mountpoint, is great enough to make up for the confusion and annoyance you get when realizing that a filesystem with /usr in its name and mountpoint isn't actually mounted at /usr and doesn't contain any data from the /usr directory. There are multiple threads on these forums of people trying to figure out why they can't mount a particular filesystem, or why what they're looking for isn't where they think it should be.

Giving parent datasets a mountpoint of "none" and non-canonical names makes the different dataset makes the output of zfs list easier for me to read, since the dataset hierarchy is more distinguishable from the filesystem hierarchy. I've only used the automated installer once, just to try it out, and didn't like the fact that it gave all the datasets nondescript names and gave them all mountpoints. Chances are the only time it will be necessary to remember that some dataset or another has canmount=off is during maintenance or disaster recovery. The rest of the time there's no reason to even think about it. I would rather go through the trouble of manually setting some mountpoints from the beginning, to avoid having to remember and deal with a confusing and unnecessary layer of abstraction when I really, really don't want to.

The parent datasets in my pool still serve the same basic purpose, though. The layout I listed is for my laptop, which only has a single 250GB SSD. Most of the datasets in the pool inherit copies=2 from tank, and most of them are included in my automatic snapshot scheme. But I don't need any redundancy or snapshots for the source tree and build output (tank/build), and while I do like to have snapshots for my media libraries I create them less frequently than I do with my other data. I already have all my media files (tank/media) stored in multiple places too, and don't need redundancy. I also don't want to run short on space someday and find myself unable to delete data, or do something stupid like accidentally delete my huge music library and then have to roll back my entire $HOME directory. So I separate those things into different dataset trees and set different properties on the parents.
 
Hi ANOKNUSA,

thank you for explaining the reason of using "none". I do agree that using the non-canonical names is actually more descriptive.

I will now search for installation how-to without the installer.

Kindest regards,

M
 
You must log in or register to reply here.
Back
Top