On Fri, Apr 17, 2020 at 1:16 PM Scott Long <scottl_at_samsco.org> wrote: > > Is the intention to eventually replace the zfs code in src/ ? Yes. Once the feature gap is filled in and most of the potential POLA violations are fixed. > What will be the long-term relationship between src/ and ports/ for this? OpenZFS users on 12 will use the port indefinitely. HEAD will presumably be updated whenever a point release is created upstream. Ultimately I can see two versions of the port, one that tracks master for HEAD and 12 and one that tracks only the latest release for 12 users. -M > > Scott > > > > On Apr 17, 2020, at 12:35 PM, Ryan Moeller <freqlabs_at_FreeBSD.org> 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. > > > > 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: > > > > 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 > > _at__at_ -25,6 +25,13 _at__at_ 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_at_freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org" > > _______________________________________________ > freebsd-current_at_freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"Received on Fri Apr 17 2020 - 20:12:07 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:23 UTC