March OpenZFS Leadership Meeting

Matthew Ahrens mahrens at delphix.com
Wed Mar 27 16:06:29 UTC 2019


At yesterday's meeting we discussed:

   - log spacemap review
   - DRAID summit
   - default pool features
   - filesystem GUIDs.

Video recording available: https://www.youtube.com/watch?v=tVhf4ZxfB1Y

The next meeting will be April 23rd at 11AM Pacific time (2 hours earlier
than usual).

Detailed notes, thanks to Karyn:

   -

   Log spacemap is out for review
   <https://github.com/zfsonlinux/zfs/pull/8442> (Serapheim)
   -

      Open PR for this work, including performance results
      -

      For people who want to port this feature to another platform,
      Serapheim also has a list of other changes required
      -

   DRAID summit (Richard Elling)
   -

      This work has been progressing, and it is at the point where it would
      be great to get people together in a conference room (physically and
      virtually) for a day to hash it all out. We would do this in the May/June
      timeframe.
      -

      Please raise your hand (click yes in the participants window) if you
      want to participate.
      -

      Working on finding the venue.
      -

      Yes votes: Joyent, Mark Maybee, BrianB, Don Brady, Matt Ahrens, Tom
      Caputti. Please reach out to Richard if you are interested in
participating.
      -

   Default pool features (Josh P)
   -

      Summary of the proposal
      -

         Portable, current, and what was available in 20XX + Tier 1
         platforms
         -

         Tier 1 platforms: FreeBSD (11.X), ZoL (0.7.X), illumos-gate (from
         1 year ago)
         -

         zpool status or upgrade would use the previously selected
         portability setting
         -

      Questions raised:
      -

         Ability to define the feature sets at runtime, so you can add new
         definitions on your own
         -

            Sef: Disagrees with the editable file. My own suggested
            addition would be the ability to query an existing pool
against portability
            list.  e.g., "How portable is this pool?" I don’t know if
that’s useful
            outside my head.
            -

         Tier 1 platform: specific ZoL version rather than a specific OS
         platform
         -

         Root pools: grub doesn’t support the same features as the Tier 1
         platforms.
         -

         Matt’s take:
         -

            User-configurable features may or may not be useful, but we can
            hold off and decide on that later.
            -

            ZoL: Which distros are shipping their own versions and how
            important are they?
            -

            Grub: We discussed this before, and we decided it was too hard
            and we were going to defer the conversation until later
            -

         Do we want to bias toward portability or the latest feature set?
         -

         Each distro ships different versions of ZoL:
         -

            RHEL has a separate repo for ZoL (0.7)
            -

            Debian ships 0.6.x
            -

               Matt: If you aren’t shipping your own version of ZoL, you
               aren’t a Tier 1 platform?
               -

         Since portability isn’t turned on by default, maybe it’s fine
         -

         You could say that only RHEL & SLES (+Ubuntu) are the platforms
         that matter since they are large, supported releases. Focus
on main distros
         and release versions
         -

         Ubuntu LTS will be Tier 1
         -

         Christian: Heard a rumor that Canonical is working on an installer
         that will include ZoL. Is that happening? What will that mean for
         portability?
         -

            Canonical are working on it, but we don’t have all the details.
            -

         Jorgen: Considering that "upgrading" is one-way - you need to be
         conservative. At the moment, users want to dual boot Windows
and Linux, and
         don't care they are missing "userobj quota" as it's not
exactly going to
         make the pool faster.
         -

         JoshP: Boot pool is not nearly as important as data pools
         -

      No volunteers to lead the implementation effort.
      -

         Suggestion to have the discussion on the mailing list to make sure
         people are included.
         -

         Matt pointed out that the person leading the implementation gets
         to decide the details beyond what’s in the core requirements.
(subject to
         code review)
         -

   Feature idea: GUIDs for filesystems that are invariant to zfs send |
   recv  (Christian)
   -

      `guid` is publicly documented since
      https://github.com/zfsonlinux/zfs/pull/6102
      -

      The `guid` property for snapshots is invariant to zfs send | recv
      -

      I use `guid` in zrepl to build diffs of the snapshot lists between
      “the same” filesystem on the sending & receiving side.
      -

      However, filesystem identity is currently derived from the dataset
      path. The `guid` for a sent-recvd filesystem is different on the
receiving
      side, hence not invariant.
      -

      Filesystem identity across pools / machines is required to reliably
      track renames & destroys of filesystems for purposes of replication.
      -

      Question: Do we want such a cross-pool `guid` for filesystems _in_
      ZFS?
      -

         Previous work & ideas in that area?
         -

         How does a receiving pool handle an (unlikely) collision of GUIDs?
         -

            Do we have this problem for snapshots already?
            -

         Alternative: implement it as a user-property.
         -

      JoshC: How does -R work with this?
      -

         Matt: It is in userland, and it does work. When you send, it has
         the from guid and you send it to the new guid. You don’t
necessarily know
         the name if it has been renamed, but you can find the
snapshot that has the
         same guid as the from guid that the send stream is describing. You can
         receive the same snapshot in one pool. The problem is
solvable with the
         solution today.
         -

         Christian: Exhaustive search is good, but it can get tricky if
         there is divergence and deleted ... Wants reliable detection mechanism.
         -

      No clear conclusion on this, and Christian also doesn’t have time to
      implement this on his own at this point.
      -

         Matt is open to someone implementing a guid for zrepl / other
         ZFS-specific functions.
         -

            For pjd’s need: Exclude these sub-filesystems or metadata. Use
            redacted send/receive (+ more stuff)


On Tue, Mar 26, 2019 at 9:29 AM Matthew Ahrens <mahrens at delphix.com> wrote:

> The next OpenZFS Leadership meeting will be held today, March 26, 1pm-2pm
> Pacific time.
>
> 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
>


More information about the freebsd-fs mailing list