The headline used here is completely misleading. They're ADDING support, not removing it.
"OpenZFS has not yet officially supported PREEMPT_RT kernels. Since Linux 6.12, PREEMPT_RT has been merged into the mainline kernel, making such configurations more accessible; however, this does not imply that OpenZFS has been validated against them. The build may fail, and even if it succeeds, compatibility issues and instability, including possible data corruption, may occur."
The only thing being added in this commit is the warning presented to users that they're at risk of instability, including data corruption with their current kernel as since 6.12, there is a new default configuration for scheduling behavior, which is worth paying attention to and so a valid concern. Debian trixie (stable) uses the 6.12 kernel for context.
ZFS is an out of tree filesystem, so one can not expect everything to go smoothly with kernel upgrades (it's recommended to hold kernel upgrades for production with ZFS, and test thoroughly, but here 6.12 is already a default for trixie), so this commit is a good road-sign to throw up infront of users to stop and think. Debian's opt-in usage stats (popcon) suggests that ZFS usage is a bit of niche, but I figured it is post worthy here, as some of us are in exactly that kind of niche.
> This option reduces the latency of the kernel by adding more "explicit preemption points" to the kernel code. These new preemption points have been selected to reduce the maximum latency of rescheduling, providing faster application reactions, at the cost of slightly lower throughput.
> This allows reaction to interactive events by allowing a low priority process to voluntarily preempt itself even if it is in kernel mode executing a system call. This allows applications to run more 'smoothly' even when the system is under load.
It is possible to boot with preempt=none on 6.12, and on 6.13 preempt=lazy was introduced, where "the task gets one HZ tick time to yield itself" before being forced.
The headline used here is completely misleading. They're ADDING support, not removing it.
"OpenZFS has not yet officially supported PREEMPT_RT kernels. Since Linux 6.12, PREEMPT_RT has been merged into the mainline kernel, making such configurations more accessible; however, this does not imply that OpenZFS has been validated against them. The build may fail, and even if it succeeds, compatibility issues and instability, including possible data corruption, may occur."
The only thing being added in this commit is the warning presented to users that they're at risk of instability, including data corruption with their current kernel as since 6.12, there is a new default configuration for scheduling behavior, which is worth paying attention to and so a valid concern. Debian trixie (stable) uses the 6.12 kernel for context.
ZFS is an out of tree filesystem, so one can not expect everything to go smoothly with kernel upgrades (it's recommended to hold kernel upgrades for production with ZFS, and test thoroughly, but here 6.12 is already a default for trixie), so this commit is a good road-sign to throw up infront of users to stop and think. Debian's opt-in usage stats (popcon) suggests that ZFS usage is a bit of niche, but I figured it is post worthy here, as some of us are in exactly that kind of niche.
https://www.kernel.org/doc/html/v6.12/admin-guide/kernel-par...
The defconfig for applicable platforms sets preempt=voluntary https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
At boot, on Debian trixie the preempt setting is printed: May 28 22:58:07 foo kernel: Dynamic Preempt: voluntary
Description from the 6.12 Kconfig: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
> This option reduces the latency of the kernel by adding more "explicit preemption points" to the kernel code. These new preemption points have been selected to reduce the maximum latency of rescheduling, providing faster application reactions, at the cost of slightly lower throughput.
> This allows reaction to interactive events by allowing a low priority process to voluntarily preempt itself even if it is in kernel mode executing a system call. This allows applications to run more 'smoothly' even when the system is under load.
It is possible to boot with preempt=none on 6.12, and on 6.13 preempt=lazy was introduced, where "the task gets one HZ tick time to yield itself" before being forced.
https://www.kernel.org/doc/html/v6.13/admin-guide/kernel-par... https://lwn.net/Articles/994322/
Linux 7.0 retains preempt=lazy and preempt=full, and there was a recent HN discussion of PostgreSQL navigating the change on the LKML:
https://news.ycombinator.com/item?id=47644864 https://lore.kernel.org/lkml/yr3inlzesdb45n6i6lpbimwr7b25kqk...
"RT kernels"