On Mon, Sep 21, 2026 at 04:28:14PM +0200, Niklas Cassel wrote: > The field described the largest zone append that a backend accepts. It > had one writer and one reader, and neither is left. > > file-posix filled it from the zone_append_max_bytes queue attribute, > which bounds REQ_OP_ZONE_APPEND, an operation it never issues: Linux has > no userspace interface for one, so raw_co_zone_append() substitutes the > write pointer of the zone for the offset and the request reaches the > host as a plain pwritev(). > > The transfer limit does not apply either, no more than it does to an > ordinary write. This driver reports max_hw_transfer but never sets > BlockLimits.max_transfer, which is what bdrv_aligned_pwritev() splits > by, so a request of any size goes to the host kernel whole and is split > there: on a null_blk device whose zone_append_max_bytes is 130560, a > 16 MiB append completes and advances the write pointer by 16 MiB. That > is safe for a sequential zone, as Linux issues the fragments of a split > write in order, with zone write plugging since 6.10 and zone write > locking before that. > > virtio-blk was the reader, and now takes what it reports to a guest from > a property instead. > > Remove the field and the assignment that filled it. Keeping it would be > worse than not having it: a driver that set it, believing something > enforced it, would be silently ignored. > > Signed-off-by: Niklas Cassel <[email protected]> > --- > block/file-posix.c | 5 ----- > include/block/block_int-common.h | 3 --- > 2 files changed, 8 deletions(-)
Reviewed-by: Stefan Hajnoczi <[email protected]>
signature.asc
Description: PGP signature
