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-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: support of PCIe NVME drives
On Fri, 17 Apr 2020 08:17:56 +0200 Miroslav Lachman 000.f...@quip.cz said Chris wrote on 04/17/2020 05:51: > On Thu, 16 Apr 2020 19:57:21 -0700 Mel Pilgrim > list_free...@bluerosetech.com said > >> On 2020-04-16 12:30, Miroslav Lachman wrote: >> > Pete Wright wrote on 04/16/2020 20:23: >> >> >> >> >> >> On 4/16/20 11:12 AM, Miroslav Lachman wrote: >> >>> Kurt Jaeger wrote on 04/16/2020 20:07: >> > >> I would try booting via UEFI if you can. I just installed a >> laptop >> yesterday which has a nvme root device, it was detected by >> the >> 12-STABLE snapshot I used to boot from. no other modifications >> were >> necessary on my end. >> > > I changed BIOS settings to use UEFI boot method, booted 12.1 >> installer > ISO but without luck. Still no NVME disks :( >> > > You can see it on printscreen from iDRAC https://ibb.co/tPnymL7 >> > > Anything more I can test? >> >> Looking at server specs, the R6515's NVME support is only through the >> PERC S150 RAID controller. If that's the case, I'm pretty sure you're >> out of luck. The PERC S-series controllers are software-based RAID >> that require Dell's Windows or Linux drivers. You'd need a PERC >> H-series card to get support in FreeBSD. That's something I didn't expect at all. So there is nothing which can be fixed on FreeBSD side? :( >> Someone please correct me if I'm wrong? > As I mentioned. I was suspicious of this. He should be able to flash the > card, > making it a pass. I do a lot of them. If someone doesn't beat me to it. > I'll > dig through what I have, and see if I can't find the right image(s), and > program(s). This is rented dedicated machine. I cannot flash anything on it. Apologies for the late reply. Unfortunately $JOB requires me to $WORK. :( OK Given these are rentals. Probably the most I could supply for your needs are images that allow you to poll, and change settings of the controller(s). I have cd9660, and USB flash images of the utilities for the 100-300 series HBAs as provided by LSI/AvGO. They boot to (MS)DOS, or to an (U)EFI prompt. Having read what I can; the S150 controller is Software controlled (likely explaining the "S" in it's model number), and as I understand it *shouldn't* require any flashing. As I also understand you *should* be able to access control of it through UEFI configs. I *think* accessed via F2. Apologies if this comes too late, or you've already solved this. If you're still interested in the management software I have for the 100-300 series. Let me know, and I'll attach a copy, or provide a link for you as needed. --Chris I can ask the provider if they can install some card. Do you have some recommendation? What is supported by Dell and FreeBSD for ZFS? I really appreciate your help! Kind regards Miroslav Lachman ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-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&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
> > @@ -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-curr...@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
> ___
> freebsd-curr...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-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-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-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-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-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-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-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-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-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-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-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&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
> @@ -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-curr...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-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-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-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&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
@@ -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-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: support of PCIe NVME drives
On Fri, 17 Apr 2020 08:41:49 +0200 Miroslav Lachman <000.f...@quip.cz> wrote: > Miroslav Lachman wrote on 04/17/2020 08:17: > > > When I go in to menu Configuration / Controllers there is empty list. > Is this expected in case of S130? > > I would really like to fulfil the client needs and run FreeBSD on it. > But These R6515 are too new too me. The last PowerEdge I have in hand > was R610 / T20. Both working fine with FreeBSD. > can you look up the hardware using dell support? using my local one https://www.dell.com/support/home/au/en/aubsd1 and enter asset tag or serial number. It will help identify parts that were shipped. I suspect if you add an extra PCIe card it may or may not be able to boot from it? cheers, matti ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
