ZFS custom pool layout install

in future ( undefined, but i would take paper notes with me ), i plan to make fresh install, manually, with shell, hence the questions regarding pool naming and dataset layout choice.
usually poolname/ROOT/default dataset is used for system installed ( mounted as "/" ). other that some certain datasets and mountpoint used by default bsdinstall, which, i believe are well thought, but i would like to have simpler scheme. idea is to have poolname parent dataset, then poolname/system mounted as "/", where installation would be, perhaps, poolname/usr and poolname/var would be separate mountpoints. idea is to avoid complex names, such as root or ROOT words in dataset naming. would it work or make sense? would it be then possible for bectl to handle such layout? i will write down suggestions on paper
P.S. sorry for the lack of formatting in required places, i am on mobile phone, and have no internet due to very well known reasons. it is hard for me to modify text.
 
desired scheme could look as follow, so that it is more clear what i trying to achieve:

datasets mountpoint
pool/system /
pool/home /home
pool/usr /usr
pool/var /var

where "pool" is the zfs pool name of choice, can be different, just an example.
maybe, there will be some other datasets for jails, bhyve or else. /home, /usr, /var can then have canmount=on, so that datasets do not fall into boot environment and handled separately. is this scheme viable or make no sense?
 
I cannot comment about if it's useful or not to have system's fs divided up in single pools for / and /usr each - could be of advantage (such as having /var seperated [on a fast pool]), could be of disadvantage (performance loss?)

But I'd recommend to have own pool(s) for your data only,
whatever one may understand about that,
e.g. such as /home, /documents, /video, /media ... /data .... - /backups what have you
One big pool with subdirectories or single pools each.... depends on what kind of data you have, how large the amounts are and how many drives of what kind in which constellation you're planning to use for what .

Advantage:
Your data(pools) are independent from the system.


Sorry, if you already aware of that,
but I recently learned that's a (very) good idea to label your drives:
How drive association happens?
Or better cut the rubbish and directly jump to
ZFS-GPT-Labels
 

SirDice

Administrator
Staff member
Administrator
Moderator
where installation would be, perhaps, poolname/usr and poolname/var would be separate mountpoints.
poolname/usr and poolname/var are NOT separate filesystems. It's just there to make separating /usr/{ports,src,home}, /var/{audit,crash,log,mail,tmp} easier.

Code:
dice@molly:~ % zfs list -r -o name,canmount,mountpoint zroot
NAME                                      CANMOUNT  MOUNTPOINT
zroot                                     on        /zroot
zroot/ROOT                                on        none
zroot/ROOT/13.0-STABLE_2021-09-06_213229  noauto    /
zroot/ROOT/13.0-STABLE_2021-09-06_213328  noauto    /
zroot/ROOT/13.0-STABLE_2021-10-02_221125  noauto    /
zroot/ROOT/13.0-STABLE_2021-11-10_100554  noauto    /
zroot/ROOT/13.0-STABLE_2021-12-21_151848  noauto    /
zroot/ROOT/13.0-STABLE_2022-01-16_170055  noauto    /
zroot/ROOT/default                        noauto    /
zroot/usr                                 off       /usr
zroot/var                                 off       /var
zroot/var/audit                           on        /var/audit
zroot/var/crash                           on        /var/crash
zroot/var/log                             on        /var/log
zroot/var/mail                            on        /var/mail
zroot/var/tmp                             on        /var/tmp
In case you're wondering about /usr/home:
Code:
dice@molly:~ % zfs list -r -o name,canmount,mountpoint fbsd1/HOMES
NAME              CANMOUNT  MOUNTPOINT
fbsd1/HOMES       on        /usr/home
fbsd1/HOMES/dice  on        /usr/home/dice

idea is to avoid complex names, such as root or ROOT words in dataset naming.
If, at some point in time, you want to use bectl(8) or beadm(8), you must use that <pool>/ROOT/<name> structure. It's of course fine to have / directly on zroot but that does mean you can never use bectl(8)/beadm(8). You will have to move things around before you can use them. Not setting it up during the initial install, even if you don't use it right now, is just not worth it in my opinion.
 
  • Like
Reactions: mer
thank you. i have tried looking trough bectl code and I do not find strict requrement that pool/ROOT/default need be used but it has to be 3 layer deep, i.e pool/system/whatername that can be then "/". Anyway, it is discussed in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253445 and https://reviews.freebsd.org/D30636
i should have found it before asking here but i only got internet in last weeks. In there, exactly my desired layout discussed. i slightly disagree with the notion of using bectl only with default layout but i agree that only reasonable BE can be supported.
so, i can, actually use custom setup but with the fact bectl expects 3 layer datasets which is fine by me
 
i slightly disagree with the notion of using bectl only with default layout but i agree that only reasonable BE can be supported.
so, i can, actually use custom setup but with the fact bectl expects 3 layer datasets which is fine by me
I think using the default layout is a safety thing because "you know it will work with bectl and beadm", which for probably 90% of people it's fine.
The other 10%, I'd say do a lot of testing to make sure you don't break anything and you get what you need. Just make sure that what is supposed to follow a BE actually does and probably more important, what is not supposed to follow a BE doesn't.
There can be a some odd behavior like datasets or directories not having mountpoints and where do they actually wind up (I'm thinking specifically things like /usr/local).
 
Top