* [PATCH] nvme: translate zns errors to blk_status_t
@ 2020-09-09 20:33 Keith Busch
2020-09-09 20:52 ` Sagi Grimberg
` (2 more replies)
0 siblings, 3 replies; 15+ messages in thread
From: Keith Busch @ 2020-09-09 20:33 UTC (permalink / raw)
To: linux-nvme, sagi, hch; +Cc: Keith Busch
EBUSY is the appropriate errno for commands that complete with zone
resource errors.
Signed-off-by: Keith Busch <kbusch@kernel.org>
---
drivers/nvme/host/core.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index ea1fa41fbba8..aff556837115 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -249,6 +249,9 @@ static blk_status_t nvme_error_status(u16 status)
return BLK_STS_NEXUS;
case NVME_SC_HOST_PATH_ERROR:
return BLK_STS_TRANSPORT;
+ case NVME_SC_ZONE_TOO_MANY_ACTIVE:
+ case NVME_SC_ZONE_TOO_MANY_OPEN:
+ return BLK_STS_DEV_RESOURCE;
default:
return BLK_STS_IOERR;
}
--
2.24.1
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: [PATCH] nvme: translate zns errors to blk_status_t
2020-09-09 20:33 [PATCH] nvme: translate zns errors to blk_status_t Keith Busch
@ 2020-09-09 20:52 ` Sagi Grimberg
2020-09-10 0:44 ` Damien Le Moal
2020-09-10 5:26 ` Christoph Hellwig
2 siblings, 0 replies; 15+ messages in thread
From: Sagi Grimberg @ 2020-09-09 20:52 UTC (permalink / raw)
To: Keith Busch, linux-nvme, hch
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] nvme: translate zns errors to blk_status_t
2020-09-09 20:33 [PATCH] nvme: translate zns errors to blk_status_t Keith Busch
2020-09-09 20:52 ` Sagi Grimberg
@ 2020-09-10 0:44 ` Damien Le Moal
2020-09-10 5:26 ` Christoph Hellwig
2 siblings, 0 replies; 15+ messages in thread
From: Damien Le Moal @ 2020-09-10 0:44 UTC (permalink / raw)
To: Keith Busch, linux-nvme, sagi, hch
On 2020/09/10 5:38, Keith Busch wrote:
> EBUSY is the appropriate errno for commands that complete with zone
> resource errors.
>
> Signed-off-by: Keith Busch <kbusch@kernel.org>
> ---
> drivers/nvme/host/core.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> index ea1fa41fbba8..aff556837115 100644
> --- a/drivers/nvme/host/core.c
> +++ b/drivers/nvme/host/core.c
> @@ -249,6 +249,9 @@ static blk_status_t nvme_error_status(u16 status)
> return BLK_STS_NEXUS;
> case NVME_SC_HOST_PATH_ERROR:
> return BLK_STS_TRANSPORT;
> + case NVME_SC_ZONE_TOO_MANY_ACTIVE:
> + case NVME_SC_ZONE_TOO_MANY_OPEN:
> + return BLK_STS_DEV_RESOURCE;
> default:
> return BLK_STS_IOERR;
> }
>
Perfect ! That fits nicely with what Johannes is working on with zonefs explicit
zone open. I will check the scsi side to make sure the same is returned for too
many open zones case.
Reviewed-by: Damien Le Moal <damien.lemoal@wdc.com>
--
Damien Le Moal
Western Digital Research
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] nvme: translate zns errors to blk_status_t
2020-09-09 20:33 [PATCH] nvme: translate zns errors to blk_status_t Keith Busch
2020-09-09 20:52 ` Sagi Grimberg
2020-09-10 0:44 ` Damien Le Moal
@ 2020-09-10 5:26 ` Christoph Hellwig
2020-09-10 14:45 ` Keith Busch
2020-09-10 22:25 ` Damien Le Moal
2 siblings, 2 replies; 15+ messages in thread
From: Christoph Hellwig @ 2020-09-10 5:26 UTC (permalink / raw)
To: Keith Busch; +Cc: sagi, linux-nvme, hch
On Wed, Sep 09, 2020 at 01:33:24PM -0700, Keith Busch wrote:
> EBUSY is the appropriate errno for commands that complete with zone
> resource errors.
>
> Signed-off-by: Keith Busch <kbusch@kernel.org>
> ---
> drivers/nvme/host/core.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> index ea1fa41fbba8..aff556837115 100644
> --- a/drivers/nvme/host/core.c
> +++ b/drivers/nvme/host/core.c
> @@ -249,6 +249,9 @@ static blk_status_t nvme_error_status(u16 status)
> return BLK_STS_NEXUS;
> case NVME_SC_HOST_PATH_ERROR:
> return BLK_STS_TRANSPORT;
> + case NVME_SC_ZONE_TOO_MANY_ACTIVE:
> + case NVME_SC_ZONE_TOO_MANY_OPEN:
> + return BLK_STS_DEV_RESOURCE;
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.
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] nvme: translate zns errors to blk_status_t
2020-09-10 5:26 ` Christoph Hellwig
@ 2020-09-10 14:45 ` Keith Busch
2020-09-10 22:25 ` Damien Le Moal
1 sibling, 0 replies; 15+ messages in thread
From: Keith Busch @ 2020-09-10 14:45 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: sagi, linux-nvme
On Thu, Sep 10, 2020 at 07:26:43AM +0200, Christoph Hellwig wrote:
> On Wed, Sep 09, 2020 at 01:33:24PM -0700, Keith Busch wrote:
> > EBUSY is the appropriate errno for commands that complete with zone
> > resource errors.
> >
> > Signed-off-by: Keith Busch <kbusch@kernel.org>
> > ---
> > drivers/nvme/host/core.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> > index ea1fa41fbba8..aff556837115 100644
> > --- a/drivers/nvme/host/core.c
> > +++ b/drivers/nvme/host/core.c
> > @@ -249,6 +249,9 @@ static blk_status_t nvme_error_status(u16 status)
> > return BLK_STS_NEXUS;
> > case NVME_SC_HOST_PATH_ERROR:
> > return BLK_STS_TRANSPORT;
> > + case NVME_SC_ZONE_TOO_MANY_ACTIVE:
> > + case NVME_SC_ZONE_TOO_MANY_OPEN:
> > + return BLK_STS_DEV_RESOURCE;
>
> 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.
I was more considering the errno the user sees going direct to the
device.
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] nvme: translate zns errors to blk_status_t
2020-09-10 5:26 ` Christoph Hellwig
2020-09-10 14:45 ` Keith Busch
@ 2020-09-10 22:25 ` Damien Le Moal
2020-09-11 6:10 ` Christoph Hellwig
1 sibling, 1 reply; 15+ messages in thread
From: Damien Le Moal @ 2020-09-10 22:25 UTC (permalink / raw)
To: Christoph Hellwig, Keith Busch; +Cc: sagi, linux-nvme
On 2020/09/10 14:34, Christoph Hellwig wrote:
> On Wed, Sep 09, 2020 at 01:33:24PM -0700, Keith Busch wrote:
>> EBUSY is the appropriate errno for commands that complete with zone
>> resource errors.
>>
>> Signed-off-by: Keith Busch <kbusch@kernel.org>
>> ---
>> drivers/nvme/host/core.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
>> index ea1fa41fbba8..aff556837115 100644
>> --- a/drivers/nvme/host/core.c
>> +++ b/drivers/nvme/host/core.c
>> @@ -249,6 +249,9 @@ static blk_status_t nvme_error_status(u16 status)
>> return BLK_STS_NEXUS;
>> case NVME_SC_HOST_PATH_ERROR:
>> return BLK_STS_TRANSPORT;
>> + case NVME_SC_ZONE_TOO_MANY_ACTIVE:
>> + case NVME_SC_ZONE_TOO_MANY_OPEN:
>> + return BLK_STS_DEV_RESOURCE;
>
> 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() ?
--
Damien Le Moal
Western Digital Research
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] nvme: translate zns errors to blk_status_t
2020-09-10 22:25 ` Damien Le Moal
@ 2020-09-11 6:10 ` Christoph Hellwig
2020-09-11 9:35 ` Damien Le Moal
0 siblings, 1 reply; 15+ messages in thread
From: Christoph Hellwig @ 2020-09-11 6:10 UTC (permalink / raw)
To: Damien Le Moal; +Cc: Keith Busch, Christoph Hellwig, linux-nvme, sagi
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.
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] nvme: translate zns errors to blk_status_t
2020-09-11 6:10 ` Christoph Hellwig
@ 2020-09-11 9:35 ` Damien Le Moal
2020-09-11 18:08 ` Keith Busch
2020-09-12 6:41 ` Christoph Hellwig
0 siblings, 2 replies; 15+ messages in thread
From: Damien Le Moal @ 2020-09-11 9:35 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Keith Busch, sagi, linux-nvme
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.
--
Damien Le Moal
Western Digital Research
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] nvme: translate zns errors to blk_status_t
2020-09-11 9:35 ` Damien Le Moal
@ 2020-09-11 18:08 ` Keith Busch
2020-09-12 6:41 ` Christoph Hellwig
1 sibling, 0 replies; 15+ messages in thread
From: Keith Busch @ 2020-09-11 18:08 UTC (permalink / raw)
To: Damien Le Moal; +Cc: Christoph Hellwig, linux-nvme, sagi
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.
It's not often I get to help define a new errno, so I'm a bit cautious
of that route. But if that's the recommendation, then sure, sounds fun.
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] nvme: translate zns errors to blk_status_t
2020-09-11 9:35 ` Damien Le Moal
2020-09-11 18:08 ` Keith Busch
@ 2020-09-12 6:41 ` Christoph Hellwig
2020-09-14 19:44 ` Keith Busch
1 sibling, 1 reply; 15+ messages in thread
From: Christoph Hellwig @ 2020-09-12 6:41 UTC (permalink / raw)
To: Damien Le Moal; +Cc: Keith Busch, Christoph Hellwig, linux-nvme, sagi
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.
>
>
> --
> Damien Le Moal
> Western Digital Research
---end quoted text---
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] nvme: translate zns errors to blk_status_t
2020-09-12 6:41 ` Christoph Hellwig
@ 2020-09-14 19:44 ` Keith Busch
2020-09-14 23:25 ` Damien Le Moal
2020-09-15 6:24 ` Christoph Hellwig
0 siblings, 2 replies; 15+ messages in thread
From: Keith Busch @ 2020-09-14 19:44 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Damien Le Moal, sagi, linux-nvme
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?
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] nvme: translate zns errors to blk_status_t
2020-09-14 19:44 ` Keith Busch
@ 2020-09-14 23:25 ` Damien Le Moal
2020-09-15 2:55 ` Keith Busch
2020-09-15 6:24 ` Christoph Hellwig
1 sibling, 1 reply; 15+ messages in thread
From: Damien Le Moal @ 2020-09-14 23:25 UTC (permalink / raw)
To: Keith Busch, Christoph Hellwig; +Cc: sagi, linux-nvme
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
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] nvme: translate zns errors to blk_status_t
2020-09-14 23:25 ` Damien Le Moal
@ 2020-09-15 2:55 ` Keith Busch
2020-09-15 2:57 ` Damien Le Moal
0 siblings, 1 reply; 15+ messages in thread
From: Keith Busch @ 2020-09-15 2:55 UTC (permalink / raw)
To: Damien Le Moal; +Cc: Christoph Hellwig, linux-nvme, sagi
On Mon, Sep 14, 2020 at 11:25:08PM +0000, Damien Le Moal wrote:
> On 2020/09/15 4:44, Keith Busch wrote:
> > 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) :)
Gotcha, I did not realize those may have open zone limits too.
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] nvme: translate zns errors to blk_status_t
2020-09-15 2:55 ` Keith Busch
@ 2020-09-15 2:57 ` Damien Le Moal
0 siblings, 0 replies; 15+ messages in thread
From: Damien Le Moal @ 2020-09-15 2:57 UTC (permalink / raw)
To: Keith Busch; +Cc: Christoph Hellwig, linux-nvme, sagi
On 2020/09/15 11:55, Keith Busch wrote:
> On Mon, Sep 14, 2020 at 11:25:08PM +0000, Damien Le Moal wrote:
>> On 2020/09/15 4:44, Keith Busch wrote:
>>> 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) :)
>
> Gotcha, I did not realize those may have open zone limits too.
ZBC/ZAC both define a max open zone limit too, which is semantically equivalent
to ZNS definition. ZBC and ZAC do not define the active zone concept though, so
no limit set for max_active_zones.
--
Damien Le Moal
Western Digital Research
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] nvme: translate zns errors to blk_status_t
2020-09-14 19:44 ` Keith Busch
2020-09-14 23:25 ` Damien Le Moal
@ 2020-09-15 6:24 ` Christoph Hellwig
1 sibling, 0 replies; 15+ messages in thread
From: Christoph Hellwig @ 2020-09-15 6:24 UTC (permalink / raw)
To: Keith Busch; +Cc: Damien Le Moal, Christoph Hellwig, linux-nvme, sagi
On Tue, Sep 15, 2020 at 04:44:21AM +0900, Keith Busch wrote:
> > 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?
As said before: most of the errno mappins are pretty arbitrary, e.g.
take a look at the -ENOLINK, -EREMOTEIO, -EBADE, -ENODATA, -EILSEQ,
or -EREMCHG mappings.
So I think just picking a value like ECHRNG or EBADSLT or EUSERS
should be perfectly fine.
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2020-09-15 6:24 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-09 20:33 [PATCH] nvme: translate zns errors to blk_status_t Keith Busch
2020-09-09 20:52 ` Sagi Grimberg
2020-09-10 0:44 ` Damien Le Moal
2020-09-10 5:26 ` Christoph Hellwig
2020-09-10 14:45 ` Keith Busch
2020-09-10 22:25 ` Damien Le Moal
2020-09-11 6:10 ` Christoph Hellwig
2020-09-11 9:35 ` Damien Le Moal
2020-09-11 18:08 ` Keith Busch
2020-09-12 6:41 ` Christoph Hellwig
2020-09-14 19:44 ` Keith Busch
2020-09-14 23:25 ` Damien Le Moal
2020-09-15 2:55 ` Keith Busch
2020-09-15 2:57 ` Damien Le Moal
2020-09-15 6:24 ` Christoph Hellwig
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.