March OpenZFS Leadership Meeting

[Matthew Ahrens]

Thanks to everyone who attended this week's meeting.  We discussed:

   - ZFS github repo move to openzfs organization
   - Progress on FreeBSD support in openzfs repo
   - directio PR

The video recording is now available:
https://www.youtube.com/watch?v=FVwYAwrKZCU&feature=youtu.be

Meeting notes:


   -

   Zfs repo move (Matt)
   -

      Which repo should they use:
      -

         If FreeBSD / ZoL, you can continue to use the same URL. There
         should be link forwarding via GitHub, and you shouldn’t have to do any
         local updates.
         -

      Code coverage links point to the wrong place, so they don’t resolve.
      At least for PRs that were open at the time when the move happened.
      Probably this won’t come up for new PRs.
      -

   FreeBSD progress (Brian)
   -

      Over the past few weeks, they’ve been getting all of the tests
      running. That’s mostly done.
      -

      There is one more big PR open to push the code (new files). Hopefully
      that will be merged this week or next.
      -

      Who is reviewing the code? Are reviewers needed?
      -

         FreeBSD folks have done reviews. Not waiting for any reviewers,
         but speak up if you have an issue.
         -

      Won’t turn on CI by default until we know the tests are passing. You
      may have to manually initiate.
      -

      Illumos is watching the progress of FreeBSD closely and will then
      look at doing something similar with illumos.
      -

   Directio (Mark M)
   -

      Motivation
      -

         Cray wanting to improve performance on NVMe drives
         -

         Sequential large-block read/write
         -

         Concerned with cost of bcopy to/from userland
         -

         With prototype, can saturate up to 12 NVMe drives (up from ~4
         without directio)
         -

      implications of directly reading/writing
      -

         Less bcopy() of buffers
         -

         Less memory is allocated (e.g. no dirty data in dbuf cache)
         -

         Data is not added to ARC cache
         -

         Write happens before call returns (but data is not necessarily
         persistent if the system crashes)
         -

         Are directio reads truly zero-copy?  How to compute checksum
         consistently?  A: It isn’t consistent. You could get a
“false” checksum
         error (hardware is fine but software caused checksum to be wrong).
         -

            Maybe add a flag to the block that indicates that the checksum
            may be faulty because it was a directio write and userland may have
            modified the block while it was being written, causing a
checksum error.
            Then handle checksum errors on these blocks differently.
            -

      User interface
      -

         Modes
         -

            Some mode that’s the same as the current behavior (ignore
            DIRECTIO request, do it the old way)
            -

            Some mode that will be the new default, which does (at least
            some) DIRECTIO-requested operations directly.
            -

            (perhaps) some mode that does i/o directly even when DIRECTIO
            is not requested.
            -

         What happens to partial-block reads that are DIRECTIO-requested?
         -

            Fail?
            -

            Fall back to normal behavior, adding block to the ARC?
            -

            Do directly, discarding non-requested data?
            -

               performance impact to sequential partial-block reads
               -

         What happens to partial-block writes that are DIRECTIO-requested?
         -

            Fail?
            -

            Fall back to normal behavior, adding block to the ARC?
            -

            Fall back to normal behavior, but don’t add block to the ARC?
            -

               I.e. write is buffered until sync context, potentially
               accumulating more changes, but after it’s written in
sync context, we
               discard it from the ARC/dbuf caches
               -

            Do directly (read-modify-write before returning)?
            -

               performance impact to sequential partial-block writes
               -

               (probably) implementation complexity
               -

            Nobody wants to argue against failing partial block writes
            -

         How does directio and regular i/o interact?
         -

            Inconsistent?
            -

               Matt says no
               -

            Consistent?
            -

               May be complicated to implement


On Mon, Mar 2, 2020 at 8:47 PM Matthew Ahrens <mahrens at delphix.com> wrote:

> The next OpenZFS Leadership meeting will be held tomorrow, March 3,
> 1pm-2pm Pacific time.  The agenda is pretty light this month, so if you
> have any topics you'd like to discuss with the group, tomorrow will be a
> good opportunity :-)
>
> 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
>