Re: CFT for vendor openzfs - week 2 reminder

From: Evilham <contact_at_evilham.com>
Date: Tue, 14 Jul 2020 00:39:33 +0200
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
Received 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