On dl., jul. 13 2020, Kyle Evans wrote:
On Mon, Jul 13, 2020 at 12:27 PM Matthew Macy
<mm...@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
_______________________________________________
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"
