On 16.03.2022 09:00, Damien Le Moal wrote:
On 3/15/22 22:05, Javier González wrote:
The main constraint for (1) PO2 is removed in the block layer, we
have (2) Linux hosts stating that unmapped LBAs are a problem,
and we have (3) HW supporting size=capacity.
I would be happy to hear what else you would like to see for this
to be of use to the kernel community.
(Added numbers to your paragraph above)
1. The sysfs chunksize attribute was "misused" to also represent
zone size. What has changed is that RAID controllers now can use a
NPO2 chunk size. This wasn't meant to naturally extend to zones,
which as shown in the current posted patchset, is a lot more work.
True. But this was the main constraint for PO2.
And as I said, users asked for it.
Now users are asking for arbitrary zone sizes.
[...]
3. I'm happy to hear that. However, I'll like to reiterate the
point that the PO2 requirement have been known for years. That
there's a drive doing NPO2 zones is great, but a decision was made
by the SSD implementors to not support the Linux kernel given its
current implementation.
Zone devices has been supported for years in SMR, and I this is a
strong argument. However, ZNS is still very new and customers have
several requirements. I do not believe that a HDD stack should have
such an impact in NVMe.
Also, we will see new interfaces adding support for zoned devices in
the future.
We should think about the future and not the past.
Backward compatibility ? We must not break userspace...
This is not a user API change. If making changes to applications to
adopt new features and technologies is breaking user-space, then the
zoned block device already broke that when we introduced zone capacity.
Any existing zoned application working on ZNS _will have to_ make
changes to support ZNS.
