Re: CFT for vendor openzfs - week 2 reminder

To help us keep track, please file an issue
https://github.com/zfsonfreebsd/zof/issues

Thanks.

On Mon, Jul 13, 2020 at 3:39 PM Evilham <contact_at_evilham.com> wrote:
>
> On dl., jul. 13 2020, Kyle Evans wrote:
>
> > On Mon, Jul 13, 2020 at 12:27 PM Matthew Macy
> > <mmacy_at_freebsd.org> wrote:
> >>
> >> On Wednesday, July 8th I issued the initial call for testing
> >> for the
> >> update to HEAD to vendored openzfs. We'd like to give users
> >> roughly a
> >> month to test before merging. The current *tentative* merge
> >> date is
> >> August 10th. I hope it's not terribly controversial to point
> >> out that
> >> it really rests with users of non amd64 platforms to test to
> >> avoid any
> >> unpleasant surprises the next time they update their trees
> >> following
> >> the merge.
> >>
> >
> > I've had no problems with this on a couple amd64 systems; I did
> > note
> > that my loader.conf's needed a good
> > s/vfs.zfs.arc_max/vfs.zfs.arc.max/
> > but I'm told a compat sysctl is on the TODO list to ease the
> > transition.
>
>
> I've also been using this on amd64 for a few days without any
> issues, it's even fixed a bug I've been trying to figure out:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247544
>
> I have noticed a thing though:
>
> Previously observed behaviour:
> 1. A new zpool is made available (e.g. geli attach)
> 2. The zpool is imported
> 3. Something happens (e.g. system reboot) and the zpool is not
> available anymore but also not exported
> 4. The zpool is made available again
> 5. The zpool is *still* imported
> 6. The zpool must be manually mounted
>
> With the patches for OpenZFS, number 5 and 6 are instead:
> 5. The data zpool is not imported
> 6. The zpool must be manually re-imported
>
> It is different behaviour, but I am very unsure about whether or
> not that is to be considered a bug and needs a PR.
> --
> Evilham