On 2020-04-18 02:27, Rodney W. Grimes wrote: >> FreeBSD support has been merged into the master branch of the openzfs/zfs >> repository, and the FreeBSD ports have been switched to this branch. >> >> OpenZFS brings many exciting features to FreeBSD, including: >> * native encryption >> * improved TRIM implementation >> * most recently, persistent L2ARC >> >> Of course, avoid upgrading your pools if you want to keep the option to go >> back to the base ZFS. > > Has anyone published a set of pool options vs *ZFS implementations so one can > figure out least common denomitator set of options when creating cross system > pools, as the trial and error method is a royal pain. >
jpaetzel@ was working with upstream on a concept where you could say 'zpool create -o compat=openzfs2020 ...', and it would make a pool compatible with the lowest common denominator across implementations as of January 2020. It has not been completed yet. >> >> OpenZFS can be installed alongside the base ZFS. Change your loader.conf >> entry to openzfs_load=?YES? to load the OpenZFS module at boot, and set PATH >> to find the tools in /usr/local/sbin before /sbin. The base zfs tools are >> still basically functional with the OpenZFS module, so changing PATH in rc >> is not strictly necessary. >> >> The FreeBSD loader can boot from pools with the encryption feature enabled, >> but the root/bootenv datasets must not be encrypted themselves. >> >> The FreeBSD platform support in OpenZFS does not yet include all features >> present in FreeBSD?s ZFS. Some notable changes/missing features include: >> * many sysctl names have changed (legacy compat sysctls should be added at >> some point) >> * zfs send progress reporting in process title via setproctitle >> * extended 'zfs holds -r' >> (https://svnweb.freebsd.org/base?view=revision&revision=290015) >> * vdev ashift optimizations >> (https://svnweb.freebsd.org/base?view=revision&revision=254591) >> * pre-mountroot zpool.cache loading (for automatic pool imports) >> >> To the last point, this mainly effects the case where / is on ZFS and /boot >> is not or is on a different pool. OpenZFS cannot handle this case yet, but >> work is in progress to cover that use case. Booting directly from ZFS does >> work. >> >> If there are pools that need to be imported at boot other than the boot >> pool, OpenZFS does not automatically import yet, and it uses >> /etc/zfs/zpool.cache rather than /boot/zfs/zpool.cache to keep track of >> imported pools. To ensure all pool imports occur automatically, a simple >> edit to /etc/rc.d/zfs will suffice: > > I am not so keen on the idea of "cache" data living in /boot, but I suppose > /boot is already tainted with per machine data that should of lived someplace > else. > The cache data has always lived in /boot/zfs in FreeBSD. It used to be required to import the pool at all, but then the boot bits got smarter. Now it is mostly only needed to know about a second or third pool you might have, so it gets imported at boot, hence how it can be replaced with the rc.d script below. >> diff --git a/libexec/rc/rc.d/zfs b/libexec/rc/rc.d/zfs >> index 2d35f9b5464..8e4aef0b1b3 100755 >> --- a/libexec/rc/rc.d/zfs >> +++ b/libexec/rc/rc.d/zfs >> @@ -25,6 +25,13 @@ zfs_start_jail() >> >> zfs_start_main() >> { >> + local cachefile >> + >> + for cachefile in /boot/zfs/zpool.cache /etc/zfs/zpool.cache; do >> + if [ -f $cachefile ]; then >> + zpool import -c $cachefile -a >> + fi >> + done >> zfs mount -va >> zfs share -a >> if [ ! -r /etc/zfs/exports ]; then >> >> This will probably not be needed long-term. It is not necessary if the boot >> pool is the only pool. >> >> Happy testing :) >> >> - Ryan >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" >> >> > -- Allan Jude _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
