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. -- EvilhamReceived on Mon Jul 13 2020 - 20:39:45 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:24 UTC