Re: OpenZFS port updated

From: Matthew Macy <mmacy_at_freebsd.org>
Date: Fri, 17 Apr 2020 15:11:54 -0700
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