From: Damien Le Moal <Damien.LeMoal@wdc.com> To: "Javier González" <javier@javigon.com>, "Matias Bjørling" <mb@lightnvm.io> Cc: "linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>, "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>, "hch@lst.de" <hch@lst.de>, "kbusch@kernel.org" <kbusch@kernel.org>, "sagi@grimberg.me" <sagi@grimberg.me>, "axboe@kernel.dk" <axboe@kernel.dk>, SelvaKumar S <selvakuma.s1@samsung.com>, Kanchan Joshi <joshi.k@samsung.com>, Nitesh Shetty <nj.shetty@samsung.com> Subject: Re: [PATCH 3/6] block: add support for zone offline transition Date: Fri, 26 Jun 2020 01:14:30 +0000 [thread overview] Message-ID: <CY4PR04MB3751E7721E5D5E15065B0ED2E7930@CY4PR04MB3751.namprd04.prod.outlook.com> (raw) In-Reply-To: 20200625194835.5hojuvdwtjxtso2l@MacBook-Pro.localdomain On 2020/06/26 4:48, Javier González wrote: > On 25.06.2020 16:12, Matias Bjørling wrote: >> On 25/06/2020 14.21, Javier González wrote: >>> From: Javier González <javier.gonz@samsung.com> >>> >>> Add support for offline transition on the zoned block device using the >>> new zone management IOCTL >>> >>> Signed-off-by: Javier González <javier.gonz@samsung.com> >>> Signed-off-by: SelvaKumar S <selvakuma.s1@samsung.com> >>> Signed-off-by: Kanchan Joshi <joshi.k@samsung.com> >>> Signed-off-by: Nitesh Shetty <nj.shetty@samsung.com> >>> --- >>> block/blk-core.c | 2 ++ >>> block/blk-zoned.c | 3 +++ >>> drivers/nvme/host/core.c | 3 +++ >>> include/linux/blk_types.h | 3 +++ >>> include/linux/blkdev.h | 1 - >>> include/uapi/linux/blkzoned.h | 1 + >>> 6 files changed, 12 insertions(+), 1 deletion(-) >>> >>> diff --git a/block/blk-core.c b/block/blk-core.c >>> index 03252af8c82c..589cbdacc5ec 100644 >>> --- a/block/blk-core.c >>> +++ b/block/blk-core.c >>> @@ -140,6 +140,7 @@ static const char *const blk_op_name[] = { >>> REQ_OP_NAME(ZONE_CLOSE), >>> REQ_OP_NAME(ZONE_FINISH), >>> REQ_OP_NAME(ZONE_APPEND), >>> + REQ_OP_NAME(ZONE_OFFLINE), >>> REQ_OP_NAME(WRITE_SAME), >>> REQ_OP_NAME(WRITE_ZEROES), >>> REQ_OP_NAME(SCSI_IN), >>> @@ -1030,6 +1031,7 @@ generic_make_request_checks(struct bio *bio) >>> case REQ_OP_ZONE_OPEN: >>> case REQ_OP_ZONE_CLOSE: >>> case REQ_OP_ZONE_FINISH: >>> + case REQ_OP_ZONE_OFFLINE: >>> if (!blk_queue_is_zoned(q)) >>> goto not_supported; >>> break; >>> diff --git a/block/blk-zoned.c b/block/blk-zoned.c >>> index 29194388a1bb..704fc15813d1 100644 >>> --- a/block/blk-zoned.c >>> +++ b/block/blk-zoned.c >>> @@ -416,6 +416,9 @@ int blkdev_zone_mgmt_ioctl(struct block_device *bdev, fmode_t mode, >>> case BLK_ZONE_MGMT_RESET: >>> op = REQ_OP_ZONE_RESET; >>> break; >>> + case BLK_ZONE_MGMT_OFFLINE: >>> + op = REQ_OP_ZONE_OFFLINE; >>> + break; >>> default: >>> return -ENOTTY; >>> } >>> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c >>> index f1215523792b..5b95c81d2a2d 100644 >>> --- a/drivers/nvme/host/core.c >>> +++ b/drivers/nvme/host/core.c >>> @@ -776,6 +776,9 @@ blk_status_t nvme_setup_cmd(struct nvme_ns *ns, struct request *req, >>> case REQ_OP_ZONE_FINISH: >>> ret = nvme_setup_zone_mgmt_send(ns, req, cmd, NVME_ZONE_FINISH); >>> break; >>> + case REQ_OP_ZONE_OFFLINE: >>> + ret = nvme_setup_zone_mgmt_send(ns, req, cmd, NVME_ZONE_OFFLINE); >>> + break; >>> case REQ_OP_WRITE_ZEROES: >>> ret = nvme_setup_write_zeroes(ns, req, cmd); >>> break; >>> diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h >>> index 16b57fb2b99c..b3921263c3dd 100644 >>> --- a/include/linux/blk_types.h >>> +++ b/include/linux/blk_types.h >>> @@ -316,6 +316,8 @@ enum req_opf { >>> REQ_OP_ZONE_FINISH = 12, >>> /* write data at the current zone write pointer */ >>> REQ_OP_ZONE_APPEND = 13, >>> + /* Transition a zone to offline */ >>> + REQ_OP_ZONE_OFFLINE = 14, >>> /* SCSI passthrough using struct scsi_request */ >>> REQ_OP_SCSI_IN = 32, >>> @@ -456,6 +458,7 @@ static inline bool op_is_zone_mgmt(enum req_opf op) >>> case REQ_OP_ZONE_OPEN: >>> case REQ_OP_ZONE_CLOSE: >>> case REQ_OP_ZONE_FINISH: >>> + case REQ_OP_ZONE_OFFLINE: >>> return true; >>> default: >>> return false; >>> diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h >>> index bd8521f94dc4..8308d8a3720b 100644 >>> --- a/include/linux/blkdev.h >>> +++ b/include/linux/blkdev.h >>> @@ -372,7 +372,6 @@ extern int blkdev_zone_ops_ioctl(struct block_device *bdev, fmode_t mode, >>> unsigned int cmd, unsigned long arg); >>> extern int blkdev_zone_mgmt_ioctl(struct block_device *bdev, fmode_t mode, >>> unsigned int cmd, unsigned long arg); >>> - >>> #else /* CONFIG_BLK_DEV_ZONED */ >>> static inline unsigned int blkdev_nr_zones(struct gendisk *disk) >>> diff --git a/include/uapi/linux/blkzoned.h b/include/uapi/linux/blkzoned.h >>> index a8c89fe58f97..d0978ee10fc7 100644 >>> --- a/include/uapi/linux/blkzoned.h >>> +++ b/include/uapi/linux/blkzoned.h >>> @@ -155,6 +155,7 @@ enum blk_zone_action { >>> BLK_ZONE_MGMT_FINISH = 0x2, >>> BLK_ZONE_MGMT_OPEN = 0x3, >>> BLK_ZONE_MGMT_RESET = 0x4, >>> + BLK_ZONE_MGMT_OFFLINE = 0x5, >>> }; >>> /** >> >> I am not sure this makes sense to expose through the kernel zone api. >> One of the goals of the kernel zone API is to be a layer that provides >> an unified zone model across SMR HDDs and ZNS SSDs. The offline zone >> operation, as defined in the ZNS specification, does not have an >> equivalent in SMR HDDs (ZAC/ZBC). >> >> This is different from the Zone Capacity change, where the zone >> capacity simply was zone size for SMR HDDs. Making it easy to support. >> That is not the same for ZAC/ZBC, that does not offer the offline >> operation to transition zones in read only state to offline state. > > I agree that an unified interface is desirable. However, the truth is > that ZAC/ZBC are different, and will differ more and more and time goes > by. We can deal with the differences at the driver level or with checks > at the API level, but limiting ZNS with ZAC/ZBC is a hard constraint. As long as you keep ZNS namespace report itself as being "host-managed" like ZBC/ZAC disks, we need the consistency and common interface. If you break that, the meaning of the zoned model queue attribute disappears and an application or in-kernel user cannot rely on this model anymore to know how the drive will behave. > Note too that I chose to only support this particular transition on the > new management IOCTL to avoid confusion for existing ZAC/ZBC users. > > It would be good to clarify what is the plan for kernel APIs moving > forward, as I believe there is a general desire to support new ZNS > features, which will not necessarily be replicated in SMR drives. What the drive is supposed to support and its behavior is determined by the zoned model. ZNS standard was written so that most things have an equivalent with ZBC/ZAC, e.g. the zone state machine is nearly identical. Differences are either emulated (e.g. zone append scsi emulation), or not supported (e.g. zone capacity change) so that the kernel follows the same pattern and maintains a coherent behavior between device protocols for the host-managed model. Think of a file system, or any other in-kernel user. If they have to change their code based on the device type (NVMe vs SCSI), then the zoned block device interface is broken. Right now, that is not the case, everything works equally well on ZNS and SCSI, modulo the need by a user for conventional zones that ZNS do not define. But that is still consistent with the host-managed model since conventional zones are optional. For this particular patch, there is currently no in-kernel user, and it is not clear how this will be useful to applications. At least please clarify this. And most likely, similarly to discard etc operations that are optional, having a sysfs attribute and in-kernel API indicating if the drive supports offlining zones will be needed. Otherwise, the caller will have to play with error codes to understand if the drive does not support the command or if it is supported but the command failed. Not nice. Better to know before issuing the command. > > Javier > -- Damien Le Moal Western Digital Research
WARNING: multiple messages have this Message-ID (diff)
From: Damien Le Moal <Damien.LeMoal@wdc.com> To: "Javier González" <javier@javigon.com>, "Matias Bjørling" <mb@lightnvm.io> Cc: "axboe@kernel.dk" <axboe@kernel.dk>, SelvaKumar S <selvakuma.s1@samsung.com>, "sagi@grimberg.me" <sagi@grimberg.me>, Kanchan Joshi <joshi.k@samsung.com>, "linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>, Nitesh Shetty <nj.shetty@samsung.com>, "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>, "kbusch@kernel.org" <kbusch@kernel.org>, "hch@lst.de" <hch@lst.de> Subject: Re: [PATCH 3/6] block: add support for zone offline transition Date: Fri, 26 Jun 2020 01:14:30 +0000 [thread overview] Message-ID: <CY4PR04MB3751E7721E5D5E15065B0ED2E7930@CY4PR04MB3751.namprd04.prod.outlook.com> (raw) In-Reply-To: 20200625194835.5hojuvdwtjxtso2l@MacBook-Pro.localdomain On 2020/06/26 4:48, Javier González wrote: > On 25.06.2020 16:12, Matias Bjørling wrote: >> On 25/06/2020 14.21, Javier González wrote: >>> From: Javier González <javier.gonz@samsung.com> >>> >>> Add support for offline transition on the zoned block device using the >>> new zone management IOCTL >>> >>> Signed-off-by: Javier González <javier.gonz@samsung.com> >>> Signed-off-by: SelvaKumar S <selvakuma.s1@samsung.com> >>> Signed-off-by: Kanchan Joshi <joshi.k@samsung.com> >>> Signed-off-by: Nitesh Shetty <nj.shetty@samsung.com> >>> --- >>> block/blk-core.c | 2 ++ >>> block/blk-zoned.c | 3 +++ >>> drivers/nvme/host/core.c | 3 +++ >>> include/linux/blk_types.h | 3 +++ >>> include/linux/blkdev.h | 1 - >>> include/uapi/linux/blkzoned.h | 1 + >>> 6 files changed, 12 insertions(+), 1 deletion(-) >>> >>> diff --git a/block/blk-core.c b/block/blk-core.c >>> index 03252af8c82c..589cbdacc5ec 100644 >>> --- a/block/blk-core.c >>> +++ b/block/blk-core.c >>> @@ -140,6 +140,7 @@ static const char *const blk_op_name[] = { >>> REQ_OP_NAME(ZONE_CLOSE), >>> REQ_OP_NAME(ZONE_FINISH), >>> REQ_OP_NAME(ZONE_APPEND), >>> + REQ_OP_NAME(ZONE_OFFLINE), >>> REQ_OP_NAME(WRITE_SAME), >>> REQ_OP_NAME(WRITE_ZEROES), >>> REQ_OP_NAME(SCSI_IN), >>> @@ -1030,6 +1031,7 @@ generic_make_request_checks(struct bio *bio) >>> case REQ_OP_ZONE_OPEN: >>> case REQ_OP_ZONE_CLOSE: >>> case REQ_OP_ZONE_FINISH: >>> + case REQ_OP_ZONE_OFFLINE: >>> if (!blk_queue_is_zoned(q)) >>> goto not_supported; >>> break; >>> diff --git a/block/blk-zoned.c b/block/blk-zoned.c >>> index 29194388a1bb..704fc15813d1 100644 >>> --- a/block/blk-zoned.c >>> +++ b/block/blk-zoned.c >>> @@ -416,6 +416,9 @@ int blkdev_zone_mgmt_ioctl(struct block_device *bdev, fmode_t mode, >>> case BLK_ZONE_MGMT_RESET: >>> op = REQ_OP_ZONE_RESET; >>> break; >>> + case BLK_ZONE_MGMT_OFFLINE: >>> + op = REQ_OP_ZONE_OFFLINE; >>> + break; >>> default: >>> return -ENOTTY; >>> } >>> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c >>> index f1215523792b..5b95c81d2a2d 100644 >>> --- a/drivers/nvme/host/core.c >>> +++ b/drivers/nvme/host/core.c >>> @@ -776,6 +776,9 @@ blk_status_t nvme_setup_cmd(struct nvme_ns *ns, struct request *req, >>> case REQ_OP_ZONE_FINISH: >>> ret = nvme_setup_zone_mgmt_send(ns, req, cmd, NVME_ZONE_FINISH); >>> break; >>> + case REQ_OP_ZONE_OFFLINE: >>> + ret = nvme_setup_zone_mgmt_send(ns, req, cmd, NVME_ZONE_OFFLINE); >>> + break; >>> case REQ_OP_WRITE_ZEROES: >>> ret = nvme_setup_write_zeroes(ns, req, cmd); >>> break; >>> diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h >>> index 16b57fb2b99c..b3921263c3dd 100644 >>> --- a/include/linux/blk_types.h >>> +++ b/include/linux/blk_types.h >>> @@ -316,6 +316,8 @@ enum req_opf { >>> REQ_OP_ZONE_FINISH = 12, >>> /* write data at the current zone write pointer */ >>> REQ_OP_ZONE_APPEND = 13, >>> + /* Transition a zone to offline */ >>> + REQ_OP_ZONE_OFFLINE = 14, >>> /* SCSI passthrough using struct scsi_request */ >>> REQ_OP_SCSI_IN = 32, >>> @@ -456,6 +458,7 @@ static inline bool op_is_zone_mgmt(enum req_opf op) >>> case REQ_OP_ZONE_OPEN: >>> case REQ_OP_ZONE_CLOSE: >>> case REQ_OP_ZONE_FINISH: >>> + case REQ_OP_ZONE_OFFLINE: >>> return true; >>> default: >>> return false; >>> diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h >>> index bd8521f94dc4..8308d8a3720b 100644 >>> --- a/include/linux/blkdev.h >>> +++ b/include/linux/blkdev.h >>> @@ -372,7 +372,6 @@ extern int blkdev_zone_ops_ioctl(struct block_device *bdev, fmode_t mode, >>> unsigned int cmd, unsigned long arg); >>> extern int blkdev_zone_mgmt_ioctl(struct block_device *bdev, fmode_t mode, >>> unsigned int cmd, unsigned long arg); >>> - >>> #else /* CONFIG_BLK_DEV_ZONED */ >>> static inline unsigned int blkdev_nr_zones(struct gendisk *disk) >>> diff --git a/include/uapi/linux/blkzoned.h b/include/uapi/linux/blkzoned.h >>> index a8c89fe58f97..d0978ee10fc7 100644 >>> --- a/include/uapi/linux/blkzoned.h >>> +++ b/include/uapi/linux/blkzoned.h >>> @@ -155,6 +155,7 @@ enum blk_zone_action { >>> BLK_ZONE_MGMT_FINISH = 0x2, >>> BLK_ZONE_MGMT_OPEN = 0x3, >>> BLK_ZONE_MGMT_RESET = 0x4, >>> + BLK_ZONE_MGMT_OFFLINE = 0x5, >>> }; >>> /** >> >> I am not sure this makes sense to expose through the kernel zone api. >> One of the goals of the kernel zone API is to be a layer that provides >> an unified zone model across SMR HDDs and ZNS SSDs. The offline zone >> operation, as defined in the ZNS specification, does not have an >> equivalent in SMR HDDs (ZAC/ZBC). >> >> This is different from the Zone Capacity change, where the zone >> capacity simply was zone size for SMR HDDs. Making it easy to support. >> That is not the same for ZAC/ZBC, that does not offer the offline >> operation to transition zones in read only state to offline state. > > I agree that an unified interface is desirable. However, the truth is > that ZAC/ZBC are different, and will differ more and more and time goes > by. We can deal with the differences at the driver level or with checks > at the API level, but limiting ZNS with ZAC/ZBC is a hard constraint. As long as you keep ZNS namespace report itself as being "host-managed" like ZBC/ZAC disks, we need the consistency and common interface. If you break that, the meaning of the zoned model queue attribute disappears and an application or in-kernel user cannot rely on this model anymore to know how the drive will behave. > Note too that I chose to only support this particular transition on the > new management IOCTL to avoid confusion for existing ZAC/ZBC users. > > It would be good to clarify what is the plan for kernel APIs moving > forward, as I believe there is a general desire to support new ZNS > features, which will not necessarily be replicated in SMR drives. What the drive is supposed to support and its behavior is determined by the zoned model. ZNS standard was written so that most things have an equivalent with ZBC/ZAC, e.g. the zone state machine is nearly identical. Differences are either emulated (e.g. zone append scsi emulation), or not supported (e.g. zone capacity change) so that the kernel follows the same pattern and maintains a coherent behavior between device protocols for the host-managed model. Think of a file system, or any other in-kernel user. If they have to change their code based on the device type (NVMe vs SCSI), then the zoned block device interface is broken. Right now, that is not the case, everything works equally well on ZNS and SCSI, modulo the need by a user for conventional zones that ZNS do not define. But that is still consistent with the host-managed model since conventional zones are optional. For this particular patch, there is currently no in-kernel user, and it is not clear how this will be useful to applications. At least please clarify this. And most likely, similarly to discard etc operations that are optional, having a sysfs attribute and in-kernel API indicating if the drive supports offlining zones will be needed. Otherwise, the caller will have to play with error codes to understand if the drive does not support the command or if it is supported but the command failed. Not nice. Better to know before issuing the command. > > Javier > -- Damien Le Moal Western Digital Research _______________________________________________ Linux-nvme mailing list Linux-nvme@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-nvme
next prev parent reply other threads:[~2020-06-26 1:14 UTC|newest] Thread overview: 140+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-06-25 12:21 [PATCH 0/6] ZNS: Extra features for current patches Javier González 2020-06-25 12:21 ` Javier González 2020-06-25 12:21 ` [PATCH 1/6] block: introduce IOCTL for zone mgmt Javier González 2020-06-25 12:21 ` Javier González 2020-06-26 1:17 ` Damien Le Moal 2020-06-26 1:17 ` Damien Le Moal 2020-06-26 6:01 ` Javier González 2020-06-26 6:01 ` Javier González 2020-06-26 6:37 ` Damien Le Moal 2020-06-26 6:37 ` Damien Le Moal 2020-06-26 6:51 ` Javier González 2020-06-26 6:51 ` Javier González 2020-06-26 7:03 ` Damien Le Moal 2020-06-26 7:03 ` Damien Le Moal 2020-06-26 7:08 ` Javier González 2020-06-26 7:08 ` Javier González 2020-06-25 12:21 ` [PATCH 2/6] block: add support for selecting all zones Javier González 2020-06-25 12:21 ` Javier González 2020-06-26 1:27 ` Damien Le Moal 2020-06-26 1:27 ` Damien Le Moal 2020-06-26 5:58 ` Javier González 2020-06-26 5:58 ` Javier González 2020-06-26 6:35 ` Damien Le Moal 2020-06-26 6:35 ` Damien Le Moal 2020-06-26 6:52 ` Javier González 2020-06-26 6:52 ` Javier González 2020-06-26 7:06 ` Damien Le Moal 2020-06-26 7:06 ` Damien Le Moal 2020-06-25 12:21 ` [PATCH 3/6] block: add support for zone offline transition Javier González 2020-06-25 12:21 ` Javier González 2020-06-25 14:12 ` Matias Bjørling 2020-06-25 14:12 ` Matias Bjørling 2020-06-25 19:48 ` Javier González 2020-06-25 19:48 ` Javier González 2020-06-26 1:14 ` Damien Le Moal [this message] 2020-06-26 1:14 ` Damien Le Moal 2020-06-26 6:18 ` Javier González 2020-06-26 6:18 ` Javier González 2020-06-26 9:11 ` hch 2020-06-26 9:11 ` hch 2020-06-26 9:15 ` Damien Le Moal 2020-06-26 9:15 ` Damien Le Moal 2020-06-26 9:17 ` hch 2020-06-26 9:17 ` hch 2020-06-26 10:02 ` Javier González 2020-06-26 10:02 ` Javier González 2020-06-26 9:07 ` Christoph Hellwig 2020-06-26 9:07 ` Christoph Hellwig 2020-06-26 1:34 ` Damien Le Moal 2020-06-26 1:34 ` Damien Le Moal 2020-06-26 6:08 ` Javier González 2020-06-26 6:08 ` Javier González 2020-06-26 6:42 ` Damien Le Moal 2020-06-26 6:42 ` Damien Le Moal 2020-06-26 6:58 ` Javier González 2020-06-26 6:58 ` Javier González 2020-06-26 7:17 ` Damien Le Moal 2020-06-26 7:17 ` Damien Le Moal 2020-06-26 7:26 ` Javier González 2020-06-26 7:26 ` Javier González 2020-06-25 12:21 ` [PATCH 4/6] block: introduce IOCTL to report dev properties Javier González 2020-06-25 12:21 ` Javier González 2020-06-25 13:10 ` Matias Bjørling 2020-06-25 13:10 ` Matias Bjørling 2020-06-25 19:42 ` Javier González 2020-06-25 19:42 ` Javier González 2020-06-25 19:58 ` Matias Bjørling 2020-06-25 19:58 ` Matias Bjørling 2020-06-26 6:24 ` Javier González 2020-06-26 6:24 ` Javier González 2020-06-25 20:25 ` Keith Busch 2020-06-25 20:25 ` Keith Busch 2020-06-26 6:28 ` Javier González 2020-06-26 6:28 ` Javier González 2020-06-26 15:52 ` Keith Busch 2020-06-26 15:52 ` Keith Busch 2020-06-26 16:25 ` Javier González 2020-06-26 16:25 ` Javier González 2020-06-26 0:57 ` Damien Le Moal 2020-06-26 0:57 ` Damien Le Moal 2020-06-26 6:27 ` Javier González 2020-06-26 6:27 ` Javier González 2020-06-26 1:38 ` Damien Le Moal 2020-06-26 1:38 ` Damien Le Moal 2020-06-26 6:22 ` Javier González 2020-06-26 6:22 ` Javier González 2020-06-25 12:21 ` [PATCH 5/6] block: add zone attr. to zone mgmt IOCTL struct Javier González 2020-06-25 12:21 ` Javier González 2020-06-25 15:13 ` Matias Bjørling 2020-06-25 15:13 ` Matias Bjørling 2020-06-25 19:51 ` Javier González 2020-06-25 19:51 ` Javier González 2020-06-26 1:45 ` Damien Le Moal 2020-06-26 1:45 ` Damien Le Moal 2020-06-26 6:03 ` Javier González 2020-06-26 6:03 ` Javier González 2020-06-26 6:38 ` Damien Le Moal 2020-06-26 6:38 ` Damien Le Moal 2020-06-26 6:49 ` Javier González 2020-06-26 6:49 ` Javier González 2020-06-26 9:14 ` Christoph Hellwig 2020-06-26 9:14 ` Christoph Hellwig 2020-06-26 10:01 ` Javier González 2020-06-26 10:01 ` Javier González 2020-06-25 12:21 ` [PATCH 6/6] nvme: Add consistency check for zone count Javier González 2020-06-25 12:21 ` Javier González 2020-06-25 13:16 ` Matias Bjørling 2020-06-25 13:16 ` Matias Bjørling 2020-06-25 19:45 ` Javier González 2020-06-25 19:45 ` Javier González 2020-06-25 21:49 ` Keith Busch 2020-06-25 21:49 ` Keith Busch 2020-06-26 0:04 ` Damien Le Moal 2020-06-26 0:04 ` Damien Le Moal 2020-06-26 6:13 ` Javier González 2020-06-26 6:13 ` Javier González 2020-06-26 6:49 ` Damien Le Moal 2020-06-26 6:49 ` Damien Le Moal 2020-06-26 6:55 ` Javier González 2020-06-26 6:55 ` Javier González 2020-06-26 7:09 ` Damien Le Moal 2020-06-26 7:09 ` Damien Le Moal 2020-06-26 7:29 ` Javier González 2020-06-26 7:29 ` Javier González 2020-06-26 7:42 ` Damien Le Moal 2020-06-26 7:42 ` Damien Le Moal 2020-06-26 9:16 ` Christoph Hellwig 2020-06-26 9:16 ` Christoph Hellwig 2020-06-26 10:03 ` Javier González 2020-06-26 10:03 ` Javier González 2020-06-25 13:04 ` [PATCH 0/6] ZNS: Extra features for current patches Matias Bjørling 2020-06-25 13:04 ` Matias Bjørling 2020-06-25 14:48 ` Matias Bjørling 2020-06-25 14:48 ` Matias Bjørling 2020-06-25 19:39 ` Javier González 2020-06-25 19:39 ` Javier González 2020-06-25 19:53 ` Matias Bjørling 2020-06-25 19:53 ` Matias Bjørling 2020-06-26 6:26 ` Javier González 2020-06-26 6:26 ` Javier González
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CY4PR04MB3751E7721E5D5E15065B0ED2E7930@CY4PR04MB3751.namprd04.prod.outlook.com \ --to=damien.lemoal@wdc.com \ --cc=axboe@kernel.dk \ --cc=hch@lst.de \ --cc=javier@javigon.com \ --cc=joshi.k@samsung.com \ --cc=kbusch@kernel.org \ --cc=linux-block@vger.kernel.org \ --cc=linux-nvme@lists.infradead.org \ --cc=mb@lightnvm.io \ --cc=nj.shetty@samsung.com \ --cc=sagi@grimberg.me \ --cc=selvakuma.s1@samsung.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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.