On Mon, 24 Aug 2020 19:38:53 -0700 Matthew Macy <mmacy_at_freebsd.org> wrote: > r364746 merged OpenZFS support in to HEAD. > > The change should be transparent unless you want to use new features. > I caution against 'zpool upgrade' for the next few weeks. > > https://svnweb.freebsd.org/base?view=revision&revision=364746 > > If you encounter problems please report them to me, Ryan Moeller, and > -current. _______________________________________________ > 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" Hello. We just upgraded several boxes running CURRENT to r365325. These systems are running customized kernels with ZFS statically compiled in. the host's OS is derived from "make buildworld buildkernel" in /usr/src. Jails on that hosts are maintained vi /etc/jail.conf, but system is installed by misusage of ezjail. So far the environemnt. One of the jails is a dedicated poudriere jail using ZFS. This worked so far. Every pool this specific jail or any other jail is mounting is located below POOL/ezjail therefore we consider enforce_statfs= "1"; in /etc/jail.conf as sufficient. After updating all /etc/default/ and /etc/rc.d of those poudriere-jails with ZFS everything should be inline regarding new requests for OpenZFS . But now enforce_statfs= "1"; isn't sufficient anymore, the jais fail to startup with a mount error complaining about insufficient access rights. The problem partially disappear by setting enforce_statfs= "0";, but this isn't what we want and personally I consider it a risk. But furthermore, several ZFS datasets prior to the upgrade successfully being exported from the hosts pools and mount from withing the jail are now invisible within the jail. According to /usr/src/UPDATING, tag 20200824, the features of the ZFS pools of the main hosts have been left untouched so far, no feature upgrade has been performed. Some hints would be nice. Kind regards, ohReceived on Fri Sep 04 2020 - 10:06:18 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:25 UTC