Add ZBD support for SMR drives to io_uring engine

[mannanal]

Hi,

We've been working with zoned block devices (ZBD) and noticed that the io_uring engines don't support zonemode=zbd, which prevents leveraging io_uring's performance benefits for zone testing workloads in SMR (Shingled Magnetic Recording) drives. This finding came from our analysis, while testing the integration of io_uring into Dropbox storage stack. An io_uring patch enabling ZBD support is also submitted.

The attached patch adds ZBD hooks to io_uring engines. The implementation is straightforward, where it delegates to the existing blkzoned, maintaining consistency with other engines.

What this enables:
- ZBD function implementations for zone management operations
- Integration with existing blkzoned interfaces
- Support for zone reporting, reset, finish, and write pointer operations in SMR/ZBD devices

I've tested this on SMR drives with the io_uring engine and it works well.

Sample fio job:

[zbd-test]
ioengine=io_uring
direct=1
bs=128k
zonemode=zbd
filename=/dev/sdg

Thanks,
Vishal Jose Mannanal

[axboe]

Before I even take a look at this patch - why did you move everything about the commit from the commit message itself, and to github where nobody will see it in the git log?

That's a nudge to amend that commit and make it a proper commit with a real change log, signed-off-by, etc.

[mannanal]

Before I even take a look at this patch - why did you move everything about the commit from the commit message itself, and to github where nobody will see it in the git log?

That's a nudge to amend that commit and make it a proper commit with a real change log, signed-off-by, etc.

Jen, Thanks for the nudge. I missed the info that commit details need to have the same info. Fixed it.

[axboe]

Thanks! Please line-wrap it at around 72 chars, and including the job file in the commit message would also be a good idea.

[mannanal]

Thanks! Please line-wrap it at around 72 chars, and including the job file in the commit message would also be a good idea.

I have updated the changes based on the above two suggestions. Thank you, Jen.

[mannanal]

CC: @damien-lemoal @yhr This PR enables ZBD capability in fio io_uring engine.

[damien-lemoal]

With io_uring, the kernel side will NOT guarantee that write commands issuing order is maintained, which leads to random unaligned write errors. This is due to the fact that io_uring may punt an IO submission to a kernel work if for whatever reason the BIO issuing blocks. Unless that is addressed first, I do not think that all this work is valid.

[mannanal]

With io_uring, the kernel side will NOT guarantee that write commands issuing order is maintained, which leads to random unaligned write errors. This is due to the fact that io_uring may punt an IO submission to a kernel work if for whatever reason the BIO issuing blocks. Unless that is addressed first, I do not think that all this work is valid.

Thanks for looking into the PR. You're right that io_uring doesn't guarantee ordering, which can be an issue for sequential zones. I'm working with SMR HDDs and making sure only one write is sent to a zone at a time. This is similar to how fio handles zonemode=zbd with io_uring, using user-space logic to avoid write pointer violations. So far this has worked well, but I agree that kernel-side ordering would make things more robust.

That said, this is not unique to io_uring, where the same applies to libaio or any other async I/O mode. As long as only one write is in flight per zone, and the write pointer is respected, it works reliably. io_uring just brings additional performance benefits like lower syscall overhead, fewer context switches, and efficient scaling across zones.

We’ve run several days of tests with SMR drives using this model and haven’t seen any issues so far. I'll be happy to compare notes if you've observed otherwise.

[mannanal]

@axboe, Since the consensus was to keep ZBD logic out of liburing, I’ve deferred those changes for now and plan to move them into a separate library when time permits.

That said, this PR is focused on fio integration and doesn’t depend on the liburing changes anymore. Let me know if we can move forward with it, or if there’s anything else I should adjust.