On 4/20/23 15:00, Damien Le Moal wrote:
On 4/21/23 02:12, Bart Van Assche wrote:
On 4/20/23 02:23, Niklas Cassel wrote:
With your change above, we would start rejecting such devices.
Is this reduction of supported NVMe ZNS SSD devices really desired?
Hi Niklas,
This is not my intention. A possible solution is to modify the NVMe
driver and SCSI core such that the "zone is full" information is stored
in struct request when a command completes. That will remove the need
for the mq-deadline scheduler to know the zone capacity.
I am not following... Why would the scheduler need to know the zone capacity ?
If the user does stupid things like accessing sectors between zone capacity and
zone size or trying to write to a full zone, the commands will be failed by the
drive and I do not see why the scheduler need to care about that.
Hi Damien,
Restricting the number of active zones in the I/O scheduler (patch
11/11) requires some knowledge of the zone condition.
According to ZBC-2, for sequential write preferred zones the additional
sense code ZONE TRANSITION TO FULL must be reported if the zone
condition changes from not full into full. There is no such requirement
for sequential write required zones. Additionally, I'm not aware of any
reporting mechanism in the NVMe specification for changes in the zone
condition.
The overhead of submitting a REPORT ZONES command after every I/O
completion would be unacceptable.
Is there any other solution for tracking the zone condition other than
comparing the LBA at which a WRITE command finished with the zone capacity?
Did I perhaps overlook something?
Thanks,
Bart.
