ZFS New to ZFS

B

bob2112

I'm not new to FreeBSD, but I am new to ZFS. I want to create a 3 drive raidz1 from a new 13.0 install with root on ZFS.
I'm keen to avoid any problems that can't be fixed without a full back-up and reinstall. I've been looking at some howtos, but lot of them seem old.

This one:

https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot

seems more up-to-date than others in that it's based on bsdinstall, rather than sysinstall, and mentions FreeBSD 12.

Is it still correct for OpenZFS on 13.0? It doesn't use raidz, but presumably I could setup three discs like that with different labelling, create a raidz pool and then follow the rest of it.

I'm unclear what the actual advantage of a UEFI Boot: is though. Are the other styles likely to fail on future motherboards?

In section 4 why do some datasets have "-o mountpoint=..." when others don't. In particular zroot/usr/ports has it but apparently equivalent datasets like zroot/var/log don't.
 
Part of the example below might help to answer part of your question.

Code: 
% zfs get mountpoint,canmount,compression august/ROOT/n251923-4bae154fe8c-a august/usr august/usr/home august/usr/ports
NAME                               PROPERTY     VALUE           SOURCE
august/ROOT/n251923-4bae154fe8c-a  mountpoint   /               local
august/ROOT/n251923-4bae154fe8c-a  canmount     noauto          local
august/ROOT/n251923-4bae154fe8c-a  compression  zstd            inherited from august
august/usr                         mountpoint   /usr            local
august/usr                         canmount     off             local
august/usr                         compression  zstd-19         received
august/usr/home                    mountpoint   /usr/home       inherited from august/usr
august/usr/home                    canmount     on              default
august/usr/home                    compression  zstd-15         received
august/usr/ports                   mountpoint   /usr/ports      inherited from august/usr
august/usr/ports                   canmount     on              default
august/usr/ports                   compression  zstd-19         inherited from august/usr
%

Whilst august/usr is not mounted, it does allow properties (such as compression) to be inherited by children such as august/usr/home.

In the example above:
  • /usr/share (not listed) uses zstd, the preferred level of compression for the file system that's currently mounted at /
  • /usr/ports uses zstd-19, inherited from (non-mounted) august/usr
  • /usr/home uses less aggressive zstd-15.

Recommended reading

zpoolconcepts.7 — OpenZFS documentation

openzfs.github.io openzfs.github.io

zfsconcepts.7 — OpenZFS documentation

openzfs.github.io openzfs.github.io
 
Yep, property inheritance is a very nice thing; as pointed out a parent dataset does not need to have a mountpoint or be mounted for child datasets to inherit.
canmount is another important property; it often works in conjunction with mountpoint to create boot environments which are one of the best features (my opinion) of doing root on ZFS.

That wiki link should work; fundamentals haven't changed.

Are you wanting to set up the raidz1 on the 3 disks to be bootable? Just asking because you may need to do extra stuff to ensure it's bootable. I'm not sure exactly what you would need to do if using UEFI boot, but I know that if you are setting up a mirrored zroot, each disk needs to have the boot code and such.
 
I still don't see why the explicit mountpoints are needed; they seem to be setting what's already the default. If there were no explicit mountpoint set for zroot/usr then zroot/usr/home would presumably still get mounted at /usr/home by inheritance.

I'm wondering if it's something to with zroot/ROOT/default being already mounted on the altroot of /mnt at the time the other datasets are created. Are the newly created datasets getting mounted as they are created, outside of /mnt, on the installers own hierarchy? That would explain the next part which has:

ln -s /usr/home /mnt/home


As regards making the drives bootable, I presume copying that file to the small fat32 file system is the way it's done. It is presented as an alternative to using "gpart bootcode ..."
 
You must log in or register to reply here.
Back
Top