> 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.

> 
> 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.

> 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"
> 
> 

-- 
Rod Grimes                                                 rgri...@freebsd.org
_______________________________________________
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"

Reply via email to