Date: Wed, 27 Feb 2019 09:04:27 -0800 From: Matthew Ahrens <mahrens@delphix.com> To: developer <developer@open-zfs.org>, illumos-zfs <zfs@lists.illumos.org>, zfs-devel@list.zfsonlinux.org, zfs-devel@freebsd.org, freebsd-fs <freebsd-fs@freebsd.org>, zfs-discuss <zfs-discuss@zfsonlinux.org> Subject: Re: February OpenZFS Leadership Meeting Message-ID: <CAJjvXiHPtefRFT9Y0Z4km9rHaTmS9p8yGxMgK-UaprVPhb0NdA@mail.gmail.com> In-Reply-To: <CAJjvXiHhhZcg_4Ju1U1F9UWRxbNyJyDdnxp89CnBCQpWvqO4xw@mail.gmail.com> References: <CAJjvXiE%2B27fYZh-RUmE=mjD4N63TrnTQVb65qaPZDj4K6oS-Rg@mail.gmail.com> <CAJjvXiE7y%2BYXAZCewDKNKXCmvMYhh4Fy0wt8Kh8V21WvYz3opg@mail.gmail.com> <CAJjvXiHhhZcg_4Ju1U1F9UWRxbNyJyDdnxp89CnBCQpWvqO4xw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At this meeting we discussed: - who will review Fast Clone Deletion - FIPS 140-2 certification - making compressed ARC mandatory - platform-specific 'sharenfs' property video recording available: https://www.youtube.com/watch?v=3DEXstK9ckcZQ meeting notes (thanks Karyn!): - Reviewers for fast clone deletion (ZoL PR <https://github.com/zfsonlinux/zfs/pull/8416>; illumos PR <https://github.com/openzfs/openzfs/pull/731>) (Sara) - There is a feature flag change that Sara sent email out about. - Sara is seeking reviewers. - Brian volunteered to review, initial pass looks great - How much review is needed? - Will have some conflicts with bpobj iteration work. - BB: Wasn=E2=80=99t planning to get this in before 0.8, but if it woul= d be useful it is possible. - Let=E2=80=99s get it in right after 0.8 (which is due out in March= ) - There are a few fixes that are pending for 0.8 to go out. Matt will look at them! - FIPS 140-2 certification (Luke) - Defense contractors could use ZFS for many things, but require FIPS. Other industries (e.g., healthcare) also have this requirement. - JC: Can you get certification for a source or is it a specific binary build? - Rainbow: It is for specific binary builds, and she does a lot of compliance and can help here. You can do source code level certification. - sef: It is really expensive and time consuming. Level of configuration for testing and certification is super specific. - BB: We do have binaries from companies like RHEL, but they aren=E2= =80=99t official builds.=E2=80=9CFIPS verified=E2=80=9D rather than certif= ied? We=E2=80=99re already using the appropriate crypto algorithm. - PD: Certifying at the source level makes it easier for a vendor to get certified. There are some additional components that would probably need to be looked at (like hash algorithms). - MA: Certification applies to the crypto algorithm. Does that help us since it is a separate module. - AJ: Different Linux distros will have different binaries that would need to be certified separately. - Luke can connect with Rainbow and sef to see what would need to be done to see if it is viable. - Should compressed ARC be mandatory? (Issue <https://github.com/zfsonlinux/zfs/issues/7896>) (Allan J) - Does anyone turn off compressed ARC? If not, we can avoid special cases for this. - Please let Allan know right away if you do turn off compressed ARC. Else that functionality may just be taken out. - MA: Seems like there are some cases on Linux where we can be confident that people aren=E2=80=99t using this combination (i.e.,= it doesn=E2=80=99t work), but that doesn=E2=80=99t cover all cases. - AJ: The crypto changes definitely made it different than what was in FreeBSD. - JC: FWIW, compressed ARC makes ARC better in many different ways in Postgres (at least). They haven=E2=80=99t noticed any latency i= ncreases or memory overhead that has been called out. - AM: It is pretty pointless to disable compressed ARC. The difference when you disable it and use other mechanisms (e.g., bcopy), is negligible and there are other benefits to keep it on. - Please comment in github! - There was no significant negative feedback, so we plan to move forward with making compressed ARC mandatory. - Platform-specific sharenfs (George) - Sent this out the proposal last night. - Create platform-specific properties. These platform-specific properties won=E2=80=99t take effect when importing the pool on a dif= ferent platform. - MA: =E2=80=98sharenfs=E2=80=99 is a system property because ZFS ta= kes action based on it (e.g. share/unshare when you do =E2=80=98zfs rename=E2=80=99= ). It should be platform-specific because the value of the property isn=E2=80=99t verified/interpreted by ZFS - it=E2=80=99s passed to the OS-specif= ic share utility without modification. - AJ: Cross-OS import is a feature I=E2=80=99d like to keep as a 1st= class citizen. - MA: JC provided feedback on the proposal. Please talk about your counter-proposal. - JC: Biggest difference was to keep the functionality the same if people really want it, but there would be a =E2=80=9Cveneer=E2=80= =9D interface that would allow platform-specific properties. Generally people would just us= e whatever properties on their OS. Garrett=E2=80=99s comments are an appliance-centric view. The key bit of the proposal is to ensure that it isn=E2=80=99t dangerous to import onto a different platform. The better eventual solution is to actually do something good in this scenario. - AJ: What about namespacing the property like we do for the user properties: sharenfs:illumos. Maybe make it more feature flag. Do it in a way that is consistent with what is already done. - CS: bikeshed: org.openzfs.illumos:sharenfs - RE: There could be many different iSCSI servers, and would need to figure out how to get to the right one. Some sharing is cross-OS: samba, nfs-ganesha - AJ: share@samba, share@nfs-ganesha, share@illumos=E2=80=A6 -- Tie = this to the server rather than OS? - JC/GW: Maybe a =E2=80=9C.=E2=80=9D instead of =E2=80=9C@=E2=80=9D? - sef: Who is going to decide if this is an OS-specific property? - CS: Have some hooks into a layer (e.g., via lua) rather than having this built into zfs. - MA: Seems like George=E2=80=99s proposal is better than what we have = now, but we should get feedback from various platform vendors. On Mon, Feb 25, 2019 at 10:53 AM Matthew Ahrens <mahrens@delphix.com> wrote= : > The next OpenZFS Leadership meeting will be held tomorrow, February 26, > 1pm-2pm Pacific time. *Note we are back to the usual time for this > meeting!* > > Everyone is welcome to attend and participate, and we will try to keep th= e > meeting on agenda and on time. The meetings will be held online via Zoom= , > and recorded and posted to the website and YouTube after the meeting. > > The agenda for the meeting will be a discussion of the projects listed in > the agenda doc. > > For more information and details on how to attend, as well as notes and > video from the previous meeting, please see the agenda document: > > > https://docs.google.com/document/d/1w2jv2XVYFmBVvG1EGf-9A5HBVsjAYoLIFZAnW= HhV-BM/edit > > --matt >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJjvXiHPtefRFT9Y0Z4km9rHaTmS9p8yGxMgK-UaprVPhb0NdA>