The OpenZFS project has shipped version 2.3.7, a maintenance release that hauls in a long list of correctness fixes for the file system that backs much of the self-hosted storage world. The headline work targets dRAID, where contributors squashed several rare-but-serious bugs including checksum errors after rebuilds with degraded disks, data corruption after a disk clear, sequential resilver reads from degraded vdevs, and import failures after disk replacements. A separate fix addresses read corruption that could occur after block cloning following a truncate, the kind of subtle interaction that has plagued the relatively young block cloning feature since its introduction.
Kernel compatibility gets a major refresh in this release. OpenZFS 2.3.7 now builds against Linux kernels from 4.18 all the way through 7.0, with shims added for the fs_context-based mount API, a new mount params parser, and workarounds for kernels that enforce previously forbidden mount options. The configure step has dropped its minimum kernel version check in favor of explicitly targeting the distros and kernels the project tests. A patch for Linux 7.1's direct access to dentry d_alias is already in place, and on the BSD side the release supports FreeBSD 13.3 and newer along with 14.0 and up, with CI now running against FreeBSD 15.1 PRERELEASE.
The deeper plumbing sees plenty of attention too. Maintainers fixed a deadlock on dmu_tx_assign() triggered by vdev_rebuild(), a range tree corruption race in dnode_sync(), a use-after-free in dmu_write_direct_done(), and a kernel BUG in mm/usercopy.c that has been tracked since issue #15918. Available space accounting for special and dedup vdevs has been corrected, kmem allocations no longer pass __GFP_RECLAIMABLE or __GFP_COMP for KM_VMEM, and libzfs now uses mount_setattr for selective remounts including legacy mounts. The team also worked around the Linux kernel's GPL-only kasan_flag_enabled symbol, a recurring pain point for the CDDL-licensed module.
OpenZFS 2.3.7 is available now from the openzfs/zfs GitHub repository, with packages expected to flow into the usual distribution channels in the coming weeks. Anyone running ZFS on root, hosting TrueNAS workloads, or maintaining home-lab pools on bleeding-edge kernels will want to keep an eye on packaging from their distro of choice.
