are you taking about separating out the home directory ?
Code:
zfs list -o name,used,referenced,canmount,mountpoint
NAME USED REFER CANMOUNT MOUNTPOINT
root 15.2G 96K on none
root/ROOT 15.2G 96K on none
root/ROOT/default 15.2G 14.9G on /
This structure is not (by a long shot) how
bsdinstall(8) as part of the default auto ZFS-on-root installation would have installed it. More importantly, this is not how BEs are intended to be structured and, almost certainly
not how you'd like the ZFS dataset structures to be implemented.
Taking the structure from the screenshot of vermaden's slide, after
zfs list -o name,canmount,mountpoint, for example:
Code:
NAME CANMOUNT MOUNTPOINT
zroot
[...]
zroot/ROOT/default noauto none
zroot/usr off /usr
zroot/usr/home on /usr/home
This kind of structure results in having your files in
/usr/home reside in the dataset
zroot/usr/home and thereby outside of any BE. This means that when switching from one BE to another, the home directories of users, including your own, stay unchanged: they fall outside of what is considered to be important to a bootable OS (read: the BEs).
If, on the other hand, all files reside in the dataset
zroot/ROOT/default, then, creating a new BE
will include the user home directories (and your home directory too of course). Any changes in your home directory for example, in an active/running BE_X are part of BE_X: booting BE_Y, not containing those changes, will therefore not display these changes in your home directory. As a small exercise, in your current set up where you've mapped
zroot/ROOT/default fully to
/, I suggest you create an extra boot environment and boot into that BE (for example with the
boot once feature), make a small change in a file in your own directory. Then boot back into your original BE and verify the status of your small change.
The same happens to more ZFS datasets, for example to
zroot/var and
zroot/var/log; the former, again, is not mounted (but has a mountpoint) and the latter is mounted to
/var/log, thereby putting it outside of any BE, thus its contents are not affected by any change of BE—as one would like. Also keep in mind: the more you let data reside in a seperate dataset (like
zroot/var/log) the less it will contribute to
each and every BE. Each newly created BE has a very small overhead size-wise,
initially. With the passing of time, BEs get bigger and bigger; this can total up to a sizeable amount; apart from the clutter from a management point of view. When you put everything in the
zroot/ROOT/default dataset, sizes of BEs increase much faster.
Usually, new users follow a path something like:
- Choose the default auto-ZFS-on-root installation by the installer.
- You get the ZFS file systems (=dataset) structure and its mappings created for you!
- Discover and learn about BEs; experiment with them.
- Use them in practical situations.
- Understand the meaning of the structure of ZFS datasets, their flexibility and other options.
- Discover and experiment with more advanced applications of BEs.
- For example "pre-installing" a complete upgrade of FreeBSD without any reboot. Pick the time of a reboot and thereby actuating the upgrade with one single reboot of the system.
You have chosen the reverse (apart from the last item I suppose), and thereby, you could say that you have thrown yourself into the deep end. As can be viewed in
Thread how-to-manually-setup-freebsd-on-zfs-root.94626, creating a ZFS-on-root structure manually isn't trivial.
In my list at
BEs & snapshots is Allan Jude's presentation of
ZFS Powered Magic Upgrades. Below the list there, I've hinted at some aspects of the flexibility of BEs and their structures. Allan Jude explains the existence of extra ZFS datasets and their mappings and why for example the filesystem (=ZFS dataset)
zroot/usr is not mounted, but has mountpoint
/usr for inheritance purposes; like shown here:
Code:
NAME CANMOUNT MOUNTPOINT
zroot
[...]
zroot/usr off /usr
zroot/usr/home on /usr/home
and why
zroot/usr/home is mounted. Alternatively, you can download the complete presentation from FOSDEM (and not be distracted by YouTube commercials):
I would say the presentation as a whole is an advanced presentation as to what potential BEs have. However, Allan's explanation of how these ZFS dataset structures are set up, how they work and what options you have, is the best I've seen. This particular explanation is from ca 5:00 min to about 8:46 where he continues with the slide "Going Further". The ZFS file system structure is in view at 6:43. I do suggest however that you also listen carefully to the part leading up to it.
Unfortunately, you now have seen three different ZFS file systems structures:
- the structure as displayed by vermaden's slide earlier in this thread
- the structure as displayed by Allan Jude in his presentation
- the structure as displayed by bectl(8) - (actually two structures)
#1 and #2 are structures how bsdinstall once created them. To the best of my knowledge, none of these three match the structure created by the current version of
bdsinstall(8).
bectl(8) even describes an alternative structure of so called "deep boot environments". All this can be rather confusing as BEs are very flexible.
If you want to create the structure as bsdinstall from your current FreeBSD release would have created it, I suggest you let bsdinstall work its magic on a separate disk with the default auto-ZFS-on-root. Then you can study (make use of
zfs list -o name,used,referenced,canmount,mountpoint) and recreate the structure onto your intended partition.
Installing FreeBSD Root on ZFS using GPT may be helpful.
Perhaps you can reinstall your release version onto your (dual booted) internal disk-partition, however, I do not have any experience with that.
