[PATCH] nvme: translate zns errors to blk_status_t

Damien Le Moal Damien.LeMoal at wdc.com
Mon Sep 14 19:25:08 EDT 2020


On 2020/09/15 4:44, Keith Busch wrote:
> On Sat, Sep 12, 2020 at 08:41:04AM +0200, Christoph Hellwig wrote:
>> On Fri, Sep 11, 2020 at 09:35:31AM +0000, Damien Le Moal wrote:
>>> On 2020/09/11 15:10, Christoph Hellwig wrote:
>>>> On Thu, Sep 10, 2020 at 10:25:24PM +0000, Damien Le Moal wrote:
>>>>>> I'm not sure this is the best idea, we probably need specific error codes
>>>>>> if we want file systems to be aware of the limit.
>>>>>
>>>>> Do you mean something else than -EBUSY being returned to the user by the block
>>>>> layer ? Or a different/specific BLK_STS_XXX code which translates into -EBUSY in
>>>>> blk_status_to_errno() ?
>>>>
>>>> My primary aim is a different BLK_STS_ code.  But given that I think
>>>> that we should not map different BLK_STS_ codes to the same errno if
>>>> we can avoid it, we should probably also use a different errno.
>>>>
>>>
>>> Hmm. Beside EBUSY, I do not see a nice existing errno that we can reuse. May be
>>> ENOSR (out of stream resources) ? Or do we define a new one ? EZBUSY ?
>>>
>>> And indeed if we define a new BLK_STS_ZONE_RESOURCE and map that to EBUSY,
>>> errno_to_blkstatus() will get confused.
>>
>> Yes, you need to pick a new error.  I don't really care which one,
>> most of the mappings are pretty odd anyway.
> 
> Selecting an existing unused errno feels a bit arbitrary for a status
> that is currently specific to NVMe ZNS. Could you provide a little more
> guidance on what you're looking for?

Not just NVMe ZNS. SCSI/ZBC and ATA/ZAC too (both sd driver) :)



-- 
Damien Le Moal
Western Digital Research



More information about the Linux-nvme mailing list