Thanks to everyone who participated.
meeting recording: https://youtu.be/WiyrHu6R8ow
Thanks Christian for these detailed notes:
-
Give an update on current status of the Direct IO PR (Brian Atkinson)
-
Will require the app to not modify memory while write is in progress,
but have an opt-in safety check in the ZIO pipeline to catch it. If it is
caught, then all of the following happen:
-
ZED event
-
zpool status message
-
write syscall fails with EINVAL
-
Check is off by default because of bcopy+checksum overhead (bcopy is
dominant)
-
Marking the page read-only to catch in-flight modification is not an
option
-
Brainstorming to avoid overhead:
-
checksum without bcopy (susceptible to transient modification)
-
opportunistic (only check in X% of cases, where X is low enough
that performance impact is low)
-
Seems like this option has consensus.
-
Concerns regarding in-flight modification & compression. Checksum
might match, but then decompression would fail. So, we need to make sure
that compression always copies the buffer, iff it’s a userspace buffer
(abd_borrow_buf_copy doesn’t guarantee copy right now).
-
Also: Brian has one weird failure on FreeBSD. Has a branch with more
debug statements & reproducer. Needs help from FreeBSD devs!
-
Zio taskq scaling for multiple pools (Allan)
-
zio_taskq_batch_pct defaults to 75% of CPU cores
-
But with N pools, we create N times those threads, which is much more
than actually available CPU cores.
-
Brainstorming session:
-
Make such taskqs global
-
Fairness & starvation shouldn’t be a problem because the taskqs
are FIFO
-
But, fear of deadlocks if taskq operations are interdependent.
Are there any?
-
Also: lock contention on taskq locks is amplified by making
them global.
-
Conclusion: not an obvious solution, system-wide taskq is worth
experimenting. (=> good hackathon project)
-
Multiple user-keys for encryption (Jonathan Waldrep)
-
UX proposal: use @ notation on the properties to distinguish
different keys (keyformat@key1, keyformat@key2, …)
-
Soliciting preferences on #11679
<https://github.com/openzfs/zfs/issues/11679> solutions (Rich)
-
NULL pointer deref on encrypted recv
-
It’s a race in which you end up taking dbuf_write’s arc_write
codepath, which temporarily NULLs the buffers of what it’s writing, while
something else ends up doing a dbuf_read -> … ->
arc_buf_untransform_in_place, which unconditionally hands the
b_pabd in to
decrypt from, and is sometimes NULL unexpectedly.
-
George: if the buffer is being written, it shouldn’t be discoverable
in the first place.
-
Rich’s Summary
<https://github.com/openzfs/zfs/issues/11679#issuecomment-1138941249>
provides details of how the condition happens.
-
George will take a look to understand why the buffer is discoverable.
-
OpenZFS Conference
-
Dates: likely early November.
-
Opportunities to help out are still available (see April 26 meeting)
On Mon, Jun 20, 2022 at 9:45 AM Matthew Ahrens <mahr...@delphix.com> wrote:
> The next OpenZFS Leadership meeting will be held tomorrow, June 21, 1pm
> 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.
>
> 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/T9f9fe51bf1909400-Mbbc16f0e98128fda03445c07
Delivery options: https://openzfs.topicbox.com/groups/developer/subscription
