OpenZFS port updated
Allan Jude
allanjude at freebsd.org
Sun Apr 19 01:20:05 UTC 2020
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 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"
>>
>>
>
--
Allan Jude
More information about the freebsd-current
mailing list