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