Hello Martin,
Sorry for the late response, still recovering from a week out of
office.
On Tue, 2021-04-06 at 00:47 -0400, Martin K. Petersen wrote:
>
> Martin,
>
> > The kernel's preference for type 8 designators (see below) is in
> > contrast with the established user space algorithms, which
Add the boolean field zone_append_not_supported to the dm_target
structure to allow a target implementing a zoned block device to
explicitly opt out from zone append (REQ_OP_ZONE_APPEND) operations
support. When set to true by the target constructor, the target device
queue limit
Synchronous writes to sequential zone files cannot use zone append
operations if the underlying zoned device queue limit
max_zone_append_sectors is 0, indicating that the device does not
support this operation. In this case, fall back to using regular write
operations.
Fixes: 02ef12a663c7
Zone append BIOs (REQ_OP_ZONE_APPEND) always specify the start sector of
the zone to be written instead of the actual location sector to write.
The write location is determined by the device and returned to the host
upon completion of the operation. This interface, while simple and
efficient for
Mike,
Zone append BIOs (REQ_OP_ZONE_APPEND) always specify the start sector
of the zone to be written instead of the actual location sector to
write. The write location is determined by the device and returned to
the host upon completion of the operation.
This interface, while simple and
On Fri, Apr 16 2021 at 7:53pm -0400,
Mike Snitzer wrote:
> Hi,
>
> This patchset reflects changes needed to make NVMe error handling and
> ANA state updates work well with dm-multipath (which always sets
> REQ_FAILFAST_TRANSPORT).
>
> RHEL8 has been carrying an older ~5.9 based version of
If the DNR bit is set we should not retry the command.
We care about the retryable vs not retryable distinction at the block
layer so propagate the equivalent of the DNR bit by introducing
BLK_STS_DO_NOT_RETRY. Update blk_path_error() to _not_ retry if it
is set.
This change runs with the
Hi,
This patchset reflects changes needed to make NVMe error handling and
ANA state updates work well with dm-multipath (which always sets
REQ_FAILFAST_TRANSPORT).
RHEL8 has been carrying an older ~5.9 based version of this patchset
(since RHEL8.3, August 2020).
RHEL9 is coming, would really
Whether or not ANA is present is a choice of the target implementation;
the host (and whether it supports multipathing) has _zero_ influence on
this. If the target declares a path as 'inaccessible' the path _is_
inaccessible to the host. As such, ANA support should be functional
even if native
REQ_FAILFAST_TRANSPORT is set by upper layer software that handles
multipathing. Unlike SCSI, NVMe's error handling was specifically
designed to handle local retry for non-path errors. As such, allow
NVMe's local retry mechanism to be used for requests marked with
REQ_FAILFAST_TRANSPORT.
In this
Whether or not ANA is present is a choice of the target implementation;
the host (and whether it supports multipathing) has _zero_ influence on
this. If the target declares a path as 'inaccessible' the path _is_
inaccessible to the host. As such, ANA support should be functional
even if native
If REQ_FAILFAST_TRANSPORT is set it means the driver should not retry
IO that completed with transport errors. REQ_FAILFAST_TRANSPORT is
set by multipathing software (e.g. dm-multipath) before it issues IO.
Update NVMe to allow failover of requests marked with either
REQ_NVME_MPATH or
From: Chao Leng
REQ_FAILFAST_TRANSPORT was designed for SCSI, because the SCSI protocol
does not define the local retry mechanism. SCSI implements a fuzzy
local retry mechanism, so REQ_FAILFAST_TRANSPORT is needed to allow
higher-level multipathing software to perform failover/retry.
NVMe is
Hi,
This patchset reflects changes needed to make NVMe error handling and
ANA state updates work well with dm-multipath (which always sets
REQ_FAILFAST_TRANSPORT).
RHEL8 has been carrying an older ~5.9 based version of this patchset
(since RHEL8.3, August 2020).
RHEL9 is coming, would really
If the DNR bit is set we should not retry the command.
We care about the retryable vs not retryable distinction at the block
layer so propagate the equivalent of the DNR bit by introducing
BLK_STS_DO_NOT_RETRY. Update blk_path_error() to _not_ retry if it
is set.
This change runs with the
On Fri, Apr 16 2021 at 4:52pm -0400,
Ewan D. Milne wrote:
> On Thu, 2021-04-15 at 19:15 -0400, Mike Snitzer wrote:
> > If REQ_FAILFAST_TRANSPORT is set it means the driver should not retry
> > IO that completed with transport errors. REQ_FAILFAST_TRANSPORT is
> > set by multipathing software
On Thu, 2021-04-15 at 19:15 -0400, Mike Snitzer wrote:
> If REQ_FAILFAST_TRANSPORT is set it means the driver should not retry
> IO that completed with transport errors. REQ_FAILFAST_TRANSPORT is
> set by multipathing software (e.g. dm-multipath) before it issues IO.
>
> Update NVMe to allow
On Fri, 2021-04-16 at 16:07 +0200, Hannes Reinecke wrote:
>
> Hmm. Quite convoluted, methinks.
> Shouldn't this achieve the same thing?
>
> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> index e89ec2522ca6..8c36a2196b66 100644
> --- a/drivers/nvme/host/core.c
> +++
On 4/16/21 5:03 PM, Mike Snitzer wrote:
> On Fri, Apr 16 2021 at 10:07am -0400,
> Hannes Reinecke wrote:
>
>> On 4/16/21 1:15 AM, Mike Snitzer wrote:
>>> If REQ_FAILFAST_TRANSPORT is set it means the driver should not retry
>>> IO that completed with transport errors. REQ_FAILFAST_TRANSPORT is
On Fri, Apr 16 2021 at 11:20am -0400,
Hannes Reinecke wrote:
> On 4/16/21 4:53 PM, Mike Snitzer wrote:
> > On Fri, Apr 16 2021 at 10:01am -0400,
> > Hannes Reinecke wrote:
> >
> >> On 4/16/21 1:15 AM, Mike Snitzer wrote:
> >>> From: Chao Leng
> >>>
> >>> REQ_FAILFAST_TRANSPORT was designed
On 4/16/21 4:53 PM, Mike Snitzer wrote:
> On Fri, Apr 16 2021 at 10:01am -0400,
> Hannes Reinecke wrote:
>
>> On 4/16/21 1:15 AM, Mike Snitzer wrote:
>>> From: Chao Leng
>>>
>>> REQ_FAILFAST_TRANSPORT was designed for SCSI, because the SCSI protocol
>>> does not define the local retry
On Fri, Apr 16 2021 at 10:07am -0400,
Hannes Reinecke wrote:
> On 4/16/21 1:15 AM, Mike Snitzer wrote:
> > If REQ_FAILFAST_TRANSPORT is set it means the driver should not retry
> > IO that completed with transport errors. REQ_FAILFAST_TRANSPORT is
> > set by multipathing software (e.g.
On Fri, Apr 16 2021 at 10:01am -0400,
Hannes Reinecke wrote:
> On 4/16/21 1:15 AM, Mike Snitzer wrote:
> > From: Chao Leng
> >
> > REQ_FAILFAST_TRANSPORT was designed for SCSI, because the SCSI protocol
> > does not define the local retry mechanism. SCSI implements a fuzzy
> > local retry
On 4/16/21 1:15 AM, Mike Snitzer wrote:
> If REQ_FAILFAST_TRANSPORT is set it means the driver should not retry
> IO that completed with transport errors. REQ_FAILFAST_TRANSPORT is
> set by multipathing software (e.g. dm-multipath) before it issues IO.
>
> Update NVMe to allow failover of
On 4/16/21 1:15 AM, Mike Snitzer wrote:
> From: Chao Leng
>
> REQ_FAILFAST_TRANSPORT was designed for SCSI, because the SCSI protocol
> does not define the local retry mechanism. SCSI implements a fuzzy
> local retry mechanism, so REQ_FAILFAST_TRANSPORT is needed to allow
> higher-level
On 4/16/21 1:15 AM, Mike Snitzer wrote:
> If the DNR bit is set we should not retry the command.
>
> We care about the retryable vs not retryable distinction at the block
> layer so propagate the equivalent of the DNR bit by introducing
> BLK_STS_DO_NOT_RETRY. Update blk_path_error() to _not_
On 16/04/2021 09:30, Damien Le Moal wrote:
> On 2021/04/16 16:13, Johannes Thumshirn wrote:
>> On 16/04/2021 05:05, Damien Le Moal wrote:
>>
>> [...]
>>
>>> + CRYPT_IV_NO_SECTORS,/* IV calculation does not use sectors
>>> */
>>
>> [...]
>>
>>> - if (ivmode == NULL)
>>> + if
On Fri, Apr 16, 2021 at 04:00:37PM +0800, Jeffle Xu wrote:
> Hi,
> How about this patch to remove the extra poll_capable() method?
>
> And the following 'dm: support IO polling for bio-based dm device' needs
> following change.
>
> ```
> + /*
> +* Check for request-based device is
Hi,
How about this patch to remove the extra poll_capable() method?
And the following 'dm: support IO polling for bio-based dm device' needs
following change.
```
+ /*
+* Check for request-based device is remained to
+*
On 4/15/21 6:06 PM, Ming Lei wrote:
> On Thu, Apr 15, 2021 at 05:21:56PM +0800, JeffleXu wrote:
>>
>>
>> On 4/15/21 3:43 PM, Ming Lei wrote:
>>> On Thu, Apr 15, 2021 at 09:34:36AM +0800, JeffleXu wrote:
On 4/14/21 7:24 PM, Ming Lei wrote:
> On Wed, Apr 14, 2021 at 04:38:25PM
On 4/15/21 3:43 PM, Ming Lei wrote:
> On Thu, Apr 15, 2021 at 09:34:36AM +0800, JeffleXu wrote:
>>
>>
>> On 4/14/21 7:24 PM, Ming Lei wrote:
>>> On Wed, Apr 14, 2021 at 04:38:25PM +0800, JeffleXu wrote:
On 4/12/21 5:38 PM, Christoph Hellwig wrote:
> On Thu, Apr 01, 2021 at
On 4/14/21 7:24 PM, Ming Lei wrote:
> On Wed, Apr 14, 2021 at 04:38:25PM +0800, JeffleXu wrote:
>>
>>
>> On 4/12/21 5:38 PM, Christoph Hellwig wrote:
>>> On Thu, Apr 01, 2021 at 10:19:26AM +0800, Ming Lei wrote:
From: Jeffle Xu
This method can be used to check if bio-based
On 2021/04/16 16:13, Johannes Thumshirn wrote:
> On 16/04/2021 05:05, Damien Le Moal wrote:
>
> [...]
>
>> +CRYPT_IV_NO_SECTORS,/* IV calculation does not use sectors
>> */
>
> [...]
>
>> -if (ivmode == NULL)
>> +if (ivmode == NULL) {
>> cc->iv_gen_ops =
On 16/04/2021 05:05, Damien Le Moal wrote:
[...]
> + CRYPT_IV_NO_SECTORS,/* IV calculation does not use sectors
> */
[...]
> - if (ivmode == NULL)
> + if (ivmode == NULL) {
> cc->iv_gen_ops = NULL;
> - else if (strcmp(ivmode, "plain") == 0)
> +
Looks good,
Reviewed-by: Johannes Thumshirn
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
Looks good,
Reviewed-by: Johannes Thumshirn
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
36 matches
Mail list logo
