[v2,0/2] block: add zone write granularity limit

Message

Damien Le Moal Jan. 19, 2021, 1:17 p.m. UTC

(resending as I forgot to add nvme and scsi lists and their
maintainers. My apologies for the noise)

The first patch in this series introduces the zone write granularity
queue limit to indicate the alignment constraint for write operations
into sequential zones of zoned block devices.

The second patch fixes adds the missing documentation for
zone_append_max_bytes to the sysfs block documentation.

Changes form v1:
* Fixed typo in patch 2

Damien Le Moal (2):
  block: introduce zone_write_granularity limit
  block: document zone_append_max_bytes attribute

 Documentation/block/queue-sysfs.rst | 13 +++++++++++++
 block/blk-settings.c                | 28 ++++++++++++++++++++++++++++
 block/blk-sysfs.c                   |  7 +++++++
 drivers/nvme/host/zns.c             |  1 +
 drivers/scsi/sd_zbc.c               | 10 ++++++++++
 include/linux/blkdev.h              |  3 +++
 6 files changed, 62 insertions(+)

Comments

Christoph Hellwig Jan. 20, 2021, 10:07 a.m. UTC | #1

Shouldn't zonefs (in addition to the pending btrfs and nvmet patches)
start using this new value instead pf the physical block size?

Damien Le Moal Jan. 20, 2021, 10:42 a.m. UTC | #2

On 2021/01/20 19:07, Christoph Hellwig wrote:
> Shouldn't zonefs (in addition to the pending btrfs and nvmet patches)
> start using this new value instead pf the physical block size?
> 

Yes for zonefs. I will add one patch to this series for that.
For nvmet patches, I will let Chaitanya handle that.
For on-going btrfs, I think we can cover that with btrfs-progs (check in mkfs)
for now and add a patch as a fix in 5.12 to check the FS block size on zoned
devices, if the series is accepted. Patching now would cause the btrfs tree to
not build.

Damien Le Moal Jan. 20, 2021, 10:46 a.m. UTC | #3

On 2021/01/20 19:07, Christoph Hellwig wrote:
> Shouldn't zonefs (in addition to the pending btrfs and nvmet patches)
> start using this new value instead pf the physical block size?
> 

And I think null_blk needs that limit set too. Forgot to add it.