Re: OpenZFS port updated
On 4/17/20, Ryan Moeller wrote: > >> On Apr 17, 2020, at 4:56 PM, Pete Wright wrote: >> >> On 4/17/20 11:35 AM, Ryan Moeller wrote: >>> OpenZFS brings many exciting features to FreeBSD, including: >>> * native encryption >> Is there a good doc reference on available for using this? I believe this >> is zfs filesystem level encryption and not a replacement for our existing >> full-disk-encryption scheme that currently works? > > I’m not aware of a good current doc for this. If anyone finds/writes > something, please post it! > There are some old resources you can find with a quick search that do a > pretty good job of covering the basic ideas, but I think the exact syntax of > commands may be slightly changed in the final implementation. > > The encryption is performed at a filesystem level (per-dataset). You could find some initial doc and video about zfs encryption on openzfs.org and youtube, and in some commit logs. Therein was mentioned... People are needed to volunteer to expand documentation on the zfs crypto subject further in some document committed to openzfs repo since users and orgs will want to know it when considering use. Volunteers are also sought by openzfs to review the crypto itself. Maybe there was already some central place made with further current documentation about the zfs encryption topics since then? https://www.youtube.com/watch?v=frnLiXclAMo openzfs encryption https://drive.google.com/file/d/0B5hUzsxe4cdmU3ZTRXNxa2JIaDQ/view https://www.youtube.com/watch?v=kFuo5bDj8C0 openzfs encryption cloud https://drive.google.com/file/d/14uIZmJ48AfaQU4q69tED6MJf-RJhgwQR/view It's dataset level, so GELI or GBDE etc are needed for full coverage, perhaps even those two may not have yet received much or formal review either, so there is always good volunteer opportunity there to start with review of a potentially simpler cryptosystem like those. zfs list, dataset snapshot names properties etc not covered. zfs history not covered, many sensitive strings will end up in there, including cutpaste password typos into commandline, usernames, timestamps, etc... and no tool exist to scrub overwrite history extents with random data, and no option exists to turn keeping of 'user initiated events' or 'long format' off, and ultimately no option exists to tell zpool create to disable history keeping from the very start entirely. So maybe users have to zero disks and pools along with it just to scrub that. zfs also exposes these variety of path and device names, timestamps, etc in cleartext on disk structures in various places, including configuration cachefile... Some of those could could be NULLed or dummied with new zpool create options for more security restricted use cases. There are other meta things and tools left exposed such as potentially any plaintext meta in send/recv. Another big metadata leak for environments and users that ship, sell, embed, clone, distribute, fileshare, and backup, their raw disks pools and usbs around to untrusted third parties... is that zfs also puts hostnames and UUID type of unique static meta and identifying things in cleartext on disk. zfs thus needs options to allow users to set and use a NULL, or generic dummy default, or random string, or chosen, "hostname" for those from the very first zpool create command. Most applications users use, including zfs, can today consider ways in which metadata leaks could be removed entirely, or at least optioned out for use under high security restricted environments modes. That could even involve considering trading off some extra features not actually required for a basic mode of functionality of the app. (cc's for fyi inclusion about leaks, and as lists still haven't been configured to support discreet bcc for that purpose, which would also maintain nice headers for thread following. Gmail breaks threads. zfsonlinux topicbox can't subscribe without web. Drop non-relevant cc's from further replies. Parent thread from freebsd current and stable lists was Subject: OpenZFS port updated)
Re: OpenZFS port updated
Il giorno ven 17 apr 2020 alle ore 20:36 Ryan Moeller
ha scritto:
> 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=290015)
> * vdev ashift optimizations (
> https://svnweb.freebsd.org/base?view=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
> @@ -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"
>
On my laptop I am testing the new OpenZFS, I am running:
> uname -a
FreeBSD NomadBSD 12.1-RELEASE-p3 FreeBSD 12.1-RELEASE-p3 GENERIC amd64
> freebsd-version -ku
12.1-RELEASE-p3
12.1-RELEASE-p4
I want let ZFS to write to the laptop SSD only every 1800 seconds:
> sudo zfs set sync=disabled zroot
and I have added these lines in /etc/sysctl.conf:
# Write to SSD every 30 minutes.
# 19/04/20 Added support for OpenZFS.
# Force commit Transaction Group (TXG) at 1800 secs, increase to aggregated
# more data (default 5 sec)
# vfs.zfs.txg.timeout for ZFS, vfs.zfs.txg_timeout for OpenZFS
vfs.zfs.txg.timeout=1800
vfs.zfs.txg_timeout=1800
# Write throttle when dirty "modified" data reaches 98% of dirty_data_max
#(default 60%)
vfs.zfs.delay_min_dirty_percent=98
# Force commit Transaction Group (TXG) if dirty_data reaches 95% of
# dirty_data_max (default 20%)
# vfs.zfs.dirty_data_sync_pct for ZFS, vfs.zfs.dirty_data_sync_percent for
OpenZFS
vfs.zfs.dirty_data_sync_pct=95
vfs.zfs.dirty_data_sync_percent=95
For testing the above settings I use the command: ‘zpool iostat -v -Td
zroot 600’ .
On the classic FreeBSD ZFS the output of the above command is similar to:
Tue Apr 28 14:44:08 CEST 2020
capacity operationsbandwidth
pool alloc free read write read write
- - - - - -
zroot 31.9G 61.1G206 38 5.52M 360K
diskid/DISK-185156448914p2 31.9G 61.1G206 38 5.52M 360K
- - - - - -
Tue Apr 28 14:54:08 CEST 2020
capacity operationsbandwidth
pool alloc free read write read write
- - - - - -
zroot 31.9G 61.1G 8 0 297K 0
Re: OpenZFS port updated
On 2020-04-18 18:16, Allan Jude wrote: If you still have a bootpool, you can migrate to a single pool (so boot environments work), using these instructions: https://ftfl.ca/blog/2016-09-17-zfs-fde-one-pool-conversion.html If the pool would boot without GELI, it still will with GELI, however, if you use any of the newer features not supported by the boot loader, then it will not be able to read the kernel from the boot (encrypted or not) My use case requires unattended booting and never storing the keyfiles on the disks to which they correspond so that, in the event of a disk failure, it can be recycled or sent back to the OEM safely. AFAIK the userkey files have to be on the same filesystem as the loader, which, for this use case, requires /boot be separate? ___ 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"
Re: OpenZFS port updated
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=290015)
>> * vdev ashift optimizations
>> (https://svnweb.freebsd.org/base?view=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"
Re: OpenZFS port updated
On 2020-04-17 17:40, Mel Pilgrim wrote: > On 2020-04-17 13:31, Kyle Evans wrote: >> On Fri, Apr 17, 2020 at 3:14 PM Mel Pilgrim >> wrote: >>> >>> On 2020-04-17 11:35, Ryan Moeller wrote: The FreeBSD platform support in OpenZFS does not yet include all features present in FreeBSD’s ZFS. Some notable changes/missing features include: >>> [...] * 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. >>> >>> To be clear, this means OpenZFS currently does not support / on >>> GELI-encrypted disks, correct? >> >> If you have a legacy setup with a bootpool, that is correct. Since >> 12.0+ the bootpool is almost completely redundant except for some odd >> setup that I can never remember. For legacy setups, the bootpool >> can/should be merged into your root pool if it's feasible. > > Yes, these are the "legacy" configuration with a small, unecrypted pool > containing /boot and the keys to attach the encrypted root pool. > > Could the case you're thinking of be avoiding manual entry of a password > at boot? > ___ > 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" If you still have a bootpool, you can migrate to a single pool (so boot environments work), using these instructions: https://ftfl.ca/blog/2016-09-17-zfs-fde-one-pool-conversion.html If the pool would boot without GELI, it still will with GELI, however, if you use any of the newer features not supported by the boot loader, then it will not be able to read the kernel from the boot (encrypted or not) -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: OpenZFS port updated
> 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=290015)
> * vdev ashift optimizations
> (https://svnweb.freebsd.org/base?view=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"
Re: OpenZFS port updated
On 4/17/20 2:54 PM, Ryan Moeller wrote: On Apr 17, 2020, at 4:56 PM, Pete Wright wrote: On 4/17/20 11:35 AM, Ryan Moeller 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. Congratulations on this effort - big milestone! OpenZFS brings many exciting features to FreeBSD, including: * native encryption Is there a good doc reference on available for using this? I believe this is zfs filesystem level encryption and not a replacement for our existing full-disk-encryption scheme that currently works? I’m not aware of a good current doc for this. If anyone finds/writes something, please post it! There are some old resources you can find with a quick search that do a pretty good job of covering the basic ideas, but I think the exact syntax of commands may be slightly changed in the final implementation. The encryption is performed at a filesystem level (per-dataset). thanks for the clarification Ryan. I may try to test this out in the near future and will try to record my findings in a wiki or somewhere. being able to do filesystem level encryption is something i have several immediate use cases for. thanks! -p -- Pete Wright p...@nomadlogic.org @nomadlogicLA ___ 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"
Re: OpenZFS port updated
On Fri, Apr 17, 2020 at 1:16 PM Scott Long 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 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=290015)
> > * vdev ashift optimizations
> > (https://svnweb.freebsd.org/base?view=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
> > @@ -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"
>
> ___
> 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"
___
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"
Re: OpenZFS port updated
> On Apr 17, 2020, at 4:56 PM, Pete Wright wrote: > > On 4/17/20 11:35 AM, Ryan Moeller 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. > Congratulations on this effort - big milestone! >> OpenZFS brings many exciting features to FreeBSD, including: >> * native encryption > Is there a good doc reference on available for using this? I believe this is > zfs filesystem level encryption and not a replacement for our existing > full-disk-encryption scheme that currently works? I’m not aware of a good current doc for this. If anyone finds/writes something, please post it! There are some old resources you can find with a quick search that do a pretty good job of covering the basic ideas, but I think the exact syntax of commands may be slightly changed in the final implementation. The encryption is performed at a filesystem level (per-dataset). > thanks again! > -pete > > -- > Pete Wright > p...@nomadlogic.org > @nomadlogicLA > > ___ > freebsd-sta...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@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"
Re: OpenZFS port updated
On 2020-04-17 13:31, Kyle Evans wrote: On Fri, Apr 17, 2020 at 3:14 PM Mel Pilgrim wrote: On 2020-04-17 11:35, Ryan Moeller wrote: The FreeBSD platform support in OpenZFS does not yet include all features present in FreeBSD’s ZFS. Some notable changes/missing features include: [...] * 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. To be clear, this means OpenZFS currently does not support / on GELI-encrypted disks, correct? If you have a legacy setup with a bootpool, that is correct. Since 12.0+ the bootpool is almost completely redundant except for some odd setup that I can never remember. For legacy setups, the bootpool can/should be merged into your root pool if it's feasible. Yes, these are the "legacy" configuration with a small, unecrypted pool containing /boot and the keys to attach the encrypted root pool. Could the case you're thinking of be avoiding manual entry of a password at boot? ___ 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"
Re: OpenZFS port updated
On 4/17/20 11:35 AM, Ryan Moeller 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. Congratulations on this effort - big milestone! OpenZFS brings many exciting features to FreeBSD, including: * native encryption Is there a good doc reference on available for using this? I believe this is zfs filesystem level encryption and not a replacement for our existing full-disk-encryption scheme that currently works? thanks again! -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA ___ 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"
Re: OpenZFS port updated
Hi, > On 17 Apr 2020, at 19:35, Ryan Moeller 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 [etc] Note that unlike native ZFS, OpenZFS doesn’t (last time I looked) support autotrim by default - you have to enable it explicitly. -- Bob Bishop r...@gid.co.uk ___ 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"
Re: OpenZFS port updated
On Fri, Apr 17, 2020 at 3:14 PM Mel Pilgrim wrote: > > On 2020-04-17 11:35, Ryan Moeller wrote: > > The FreeBSD platform support in OpenZFS does not yet include all > > features present in FreeBSD’s ZFS. Some notable changes/missing > > features include: > [...] > > * 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. > > To be clear, this means OpenZFS currently does not support / on > GELI-encrypted disks, correct? If you have a legacy setup with a bootpool, that is correct. Since 12.0+ the bootpool is almost completely redundant except for some odd setup that I can never remember. For legacy setups, the bootpool can/should be merged into your root pool if it's feasible. Thanks, Kyle Evans ___ 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"
Re: OpenZFS port updated
Is the intention to eventually replace the zfs code in src/ ? What will be the
long-term relationship between src/ and ports/ for this?
Scott
> On Apr 17, 2020, at 12:35 PM, Ryan Moeller 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=290015)
> * vdev ashift optimizations
> (https://svnweb.freebsd.org/base?view=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
> @@ -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"
___
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"
Re: OpenZFS port updated
On 2020-04-17 11:35, Ryan Moeller wrote: The FreeBSD platform support in OpenZFS does not yet include all features present in FreeBSD’s ZFS. Some notable changes/missing features include: [...] * 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. To be clear, this means OpenZFS currently does not support / on GELI-encrypted disks, correct? ___ 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"
OpenZFS port updated
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=290015)
* vdev ashift optimizations
(https://svnweb.freebsd.org/base?view=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
@@ -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"
