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=EXstK9ckcZQ 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’t planning to get this in before 0.8, but if it would be useful it is possible. - Let’s 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’t official builds.“FIPS verified” rather than certified? We’re 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’t using this combination (i.e., it doesn’t work), but that doesn’t 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’t noticed any latency increases 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’t take effect when importing the pool on a different platform. - MA: ‘sharenfs’ is a system property because ZFS takes action based on it (e.g. share/unshare when you do ‘zfs rename’). It should be platform-specific because the value of the property isn’t verified/interpreted by ZFS - it’s passed to the OS-specific share utility without modification. - AJ: Cross-OS import is a feature I’d 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 “veneer” interface that would allow platform-specific properties. Generally people would just use whatever properties on their OS. Garrett’s comments are an appliance-centric view. The key bit of the proposal is to ensure that it isn’t 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… -- Tie this to the server rather than OS? - JC/GW: Maybe a “.” instead of “@”? - 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’s 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 <[email protected]> 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 the > 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-9A5HBVsjAYoLIFZAnWHhV-BM/edit > > --matt > ------------------------------------------ openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/T7ea98f99753036e8-M6d47c1d5435c4d6d8ad8ff05 Delivery options: https://openzfs.topicbox.com/groups/developer/subscription
