February OpenZFS Leadership Meeting

Wed Feb 27 17:04:42 UTC 2019

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 at samba, share at nfs-ganesha, share at 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 <mahrens at 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 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
>