Page MenuHomeFreeBSD

nvme: Add ZNS support (WIP)
Needs ReviewPublic

Authored by ken on Tue, Oct 6, 5:50 PM.

Details

Reviewers
asomers
fuz
Group Reviewers
cam
Summary

Marked as WIP due to doubts revolving around nvd(4) behaviour, command
sets, etc. Tests are missing because of this, also awaiting feedback.

Squash of the following commits:

nda.4: Fix mandoc useless macro warning
nda: Add support for Zoned Namespaces
cam: nvme: Fetch the ZNS identify data while probing a device
disk_zone.h: Add zone capacity
nvd: Do not attach to zoned namespaces
nvme: Add Zoned Namespace Command Set definitions
nvme: Record the I/O command set of each namespace
nvme: Select every supported I/O command set
nvme: Add I/O command set identification support

Uploaded on behalf of voidanix (GSoC 2026). This is the
zns-works-with-doubts branch from
https://github.com/voidanix/freebsd-src, rebased onto main. The rebase
resolved conflicts with b99595c9c072 ("nvme: derive CC.CSS from CAP.CSS
instead of hardcoding the NVM set"): the duplicated CAP.CSS and CC.CSS
macros were dropped in favor of the names now in the tree, and the
CC.CSS selection in nvme_ctrlr_enable() now prefers all supported I/O
command sets, then the NVM command set, then no I/O command set for
administrative controllers.

Boot tested on amd64 hardware with four conventional (non-ZNS) NVMe
drives (two Phison-based PASCARI X200, two KIOXIA XG8) attached via
nda(4): all four attach cleanly, Identify and sequential reads work,
ZFS pool I/O on an nda-backed mirror works, and zone commands
(zonectl(8) and the camcontrol(8) zone subcommand) are refused exactly
as on a stock kernel. voidanix tested the zoned paths on ZNS
hardware.

Discussed with: ken, fuz, asomers
Sponsored by: Google Summer of Code 2026

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 77772
Build 74655: arc lint + arc unit

Event Timeline

ken requested review of this revision.Tue, Oct 6, 5:50 PM

Ocne this isn't WIP, please break this up into smaller chunks. It's too overwhelming to review as is.

Also, nvd's remit is 'thin as possible over namespace' which would preclude it supporting more complicated things like zoned storage. There's no good reason to expand it unless there's somebody who will be using it heavily and maintaining it. Let's just do nda for this.

The nvd(4) change here is the opposite of expanding it -- it just makes nvd decline to attach to zoned namespaces, so zoned support is nda(4)-only. So this already matches what you are suggesting, and it answers one of the doubts voidanix flagged in the WIP note.

Agreed on splitting it up. The summary lists the nine constituent commits; the plan is to put those up as a stacked series once this sheds its WIP status.