From: Judy Brock <judy.brock@samsung.com> To: "Damien Le Moal" <Damien.LeMoal@wdc.com>, "Javier González" <javier@javigon.com>, "Matias Bjørling" <mb@lightnvm.io> Cc: Jens Axboe <axboe@kernel.dk>, Niklas Cassel <Niklas.Cassel@wdc.com>, "Ajay Joshi" <Ajay.Joshi@wdc.com>, Sagi Grimberg <sagi@grimberg.me>, Keith Busch <Keith.Busch@wdc.com>, Dmitry Fomichev <Dmitry.Fomichev@wdc.com>, "Aravind Ramesh" <Aravind.Ramesh@wdc.com>, "linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>, "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>, Hans Holmberg <Hans.Holmberg@wdc.com>, Christoph Hellwig <hch@lst.de>, Matias Bjorling <Matias.Bjorling@wdc.com> Subject: RE: [PATCH 5/5] nvme: support for zoned namespaces Date: Tue, 16 Jun 2020 13:08:13 +0000 [thread overview] Message-ID: <4a97bb114ece452c80f08b96d6cbc11d@samsung.com> (raw) In-Reply-To: <CY4PR04MB3751CC8FE4BDFC256F9E9CD1E79D0@CY4PR04MB3751.namprd04.prod.outlook.com> "The on-going re-work of btrfs zone support for instance now relies 100% on zone append being supported.... So the approach is: mandate zone append support for ZNS devices.... To allow other ZNS drives, an emulation similar to SCSI can be implemented, ... While on a HDD the performance penalty is minimal, it will likely be *significant* on a SSD." Wow. Well as I said, I don't know much about Linux but it sounds like the ongoing re-work of btrfs zone support mandating zone append should be revisited. The reality is there will be flavors of ZNS drives in the market that do not support Append. As many of you know, the ZRWA technical proposal is well under-way in NVMe ZNS WG. Ensuring that the entire Linux zone support ecosystem deliberately locks these devices out / or at best consigns them to a severely performance-penalized path, especially given the MULTIPLE statements that have been made in the NVMe ZNS WG by multiple companies regarding the use cases for which Zone Append is an absolute disaster (not my words), seems pretty darn inappropriate. -----Original Message----- From: linux-nvme [mailto:linux-nvme-bounces@lists.infradead.org] On Behalf Of Damien Le Moal Sent: Tuesday, June 16, 2020 5:36 AM To: Javier González; Matias Bjørling Cc: Jens Axboe; Niklas Cassel; Ajay Joshi; Sagi Grimberg; Keith Busch; Dmitry Fomichev; Aravind Ramesh; linux-nvme@lists.infradead.org; linux-block@vger.kernel.org; Hans Holmberg; Christoph Hellwig; Matias Bjorling Subject: Re: [PATCH 5/5] nvme: support for zoned namespaces On 2020/06/16 21:24, Javier González wrote: > On 16.06.2020 14:06, Matias Bjørling wrote: >> On 16/06/2020 14.00, Javier González wrote: >>> On 16.06.2020 13:18, Matias Bjørling wrote: >>>> On 16/06/2020 12.41, Javier González wrote: >>>>> On 16.06.2020 08:34, Keith Busch wrote: >>>>>> Add support for NVM Express Zoned Namespaces (ZNS) Command Set defined >>>>>> in NVM Express TP4053. Zoned namespaces are discovered based on their >>>>>> Command Set Identifier reported in the namespaces Namespace >>>>>> Identification Descriptor list. A successfully discovered Zoned >>>>>> Namespace will be registered with the block layer as a host managed >>>>>> zoned block device with Zone Append command support. A namespace that >>>>>> does not support append is not supported by the driver. >>>>> >>>>> Why are we enforcing the append command? Append is optional on the >>>>> current ZNS specification, so we should not make this mandatory in the >>>>> implementation. See specifics below. >>> >>>> >>>> There is already general support in the kernel for the zone append >>>> command. Feel free to submit patches to emulate the support. It is >>>> outside the scope of this patchset. >>>> >>> >>> It is fine that the kernel supports append, but the ZNS specification >>> does not impose the implementation for append, so the driver should not >>> do that either. >>> >>> ZNS SSDs that choose to leave append as a non-implemented optional >>> command should not rely on emulated SW support, specially when >>> traditional writes work very fine for a large part of current ZNS use >>> cases. >>> >>> Please, remove this virtual constraint. >> >> The Zone Append command is mandatory for zoned block devices. Please >> see https://urldefense.proofpoint.com/v2/url?u=https-3A__lwn.net_Articles_818709_&d=DwIFAw&c=JfeWlBa6VbDyTXraMENjy_b_0yKWuqQ4qY-FPhxK4x8w-TfgRBDyeV4hVQQBEgL2&r=YJM_QPk2w1CRIo5NNBXnCXGzNnmIIfG_iTRs6chBf6s&m=-fIHWuFYU2GHiTJ2FuhTBgrypPIJW0FjLUWTaK4cH9c&s=kkJ8bJpiTjKS9PoobDPHTf11agXKNUpcw5AsIEyewZk&e= for the background. > > I do not see anywhere in the block layer that append is mandatory for > zoned devices. Append is emulated on ZBC, but beyond that there is no > mandatory bits. Please explain. This is to allow a single write IO path for all types of zoned block device for higher layers, e.g file systems. The on-going re-work of btrfs zone support for instance now relies 100% on zone append being supported. That significantly simplifies the file system support and more importantly remove the need for locking around block allocation and BIO issuing, allowing to preserve a fully asynchronous write path that can include workqueues for efficient CPU usage of things like encryption and compression. Without zone append, file system would either (1) have to reject these drives that do not support zone append, or (2) implement 2 different write IO path (slower regular write and zone append). None of these options are ideal, to say the least. So the approach is: mandate zone append support for ZNS devices. To allow other ZNS drives, an emulation similar to SCSI can be implemented, with that emulation ideally combined to work for both types of drives if possible. And note that this emulation would require the drive to be operated with mq-deadline to enable zone write locking for preserving write command order. While on a HDD the performance penalty is minimal, it will likely be significant on a SSD. > >> Please submitpatches if you want to have support for ZNS devices that >> does not implement the Zone Append command. It is outside the scope >> of this patchset. > > That we will. > > > _______________________________________________ > linux-nvme mailing list > linux-nvme@lists.infradead.org > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_mailman_listinfo_linux-2Dnvme&d=DwIFAw&c=JfeWlBa6VbDyTXraMENjy_b_0yKWuqQ4qY-FPhxK4x8w-TfgRBDyeV4hVQQBEgL2&r=YJM_QPk2w1CRIo5NNBXnCXGzNnmIIfG_iTRs6chBf6s&m=-fIHWuFYU2GHiTJ2FuhTBgrypPIJW0FjLUWTaK4cH9c&s=HeBnGkcBM5OqESkW8yYYi2KtvVwbdamrbd_X5PgGKBk&e= > -- Damien Le Moal Western Digital Research _______________________________________________ linux-nvme mailing list linux-nvme@lists.infradead.org https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_mailman_listinfo_linux-2Dnvme&d=DwIFAw&c=JfeWlBa6VbDyTXraMENjy_b_0yKWuqQ4qY-FPhxK4x8w-TfgRBDyeV4hVQQBEgL2&r=YJM_QPk2w1CRIo5NNBXnCXGzNnmIIfG_iTRs6chBf6s&m=-fIHWuFYU2GHiTJ2FuhTBgrypPIJW0FjLUWTaK4cH9c&s=HeBnGkcBM5OqESkW8yYYi2KtvVwbdamrbd_X5PgGKBk&e=
WARNING: multiple messages have this Message-ID (diff)
From: Judy Brock <judy.brock@samsung.com> To: "Damien Le Moal" <Damien.LeMoal@wdc.com>, "Javier González" <javier@javigon.com>, "Matias Bjørling" <mb@lightnvm.io> Cc: Jens Axboe <axboe@kernel.dk>, Niklas Cassel <Niklas.Cassel@wdc.com>, Ajay Joshi <Ajay.Joshi@wdc.com>, Sagi Grimberg <sagi@grimberg.me>, Keith Busch <Keith.Busch@wdc.com>, Dmitry Fomichev <Dmitry.Fomichev@wdc.com>, Aravind Ramesh <Aravind.Ramesh@wdc.com>, "linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>, "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>, Hans Holmberg <Hans.Holmberg@wdc.com>, Christoph Hellwig <hch@lst.de>, Matias Bjorling <Matias.Bjorling@wdc.com> Subject: RE: [PATCH 5/5] nvme: support for zoned namespaces Date: Tue, 16 Jun 2020 13:08:13 +0000 [thread overview] Message-ID: <4a97bb114ece452c80f08b96d6cbc11d@samsung.com> (raw) In-Reply-To: <CY4PR04MB3751CC8FE4BDFC256F9E9CD1E79D0@CY4PR04MB3751.namprd04.prod.outlook.com> "The on-going re-work of btrfs zone support for instance now relies 100% on zone append being supported.... So the approach is: mandate zone append support for ZNS devices.... To allow other ZNS drives, an emulation similar to SCSI can be implemented, ... While on a HDD the performance penalty is minimal, it will likely be *significant* on a SSD." Wow. Well as I said, I don't know much about Linux but it sounds like the ongoing re-work of btrfs zone support mandating zone append should be revisited. The reality is there will be flavors of ZNS drives in the market that do not support Append. As many of you know, the ZRWA technical proposal is well under-way in NVMe ZNS WG. Ensuring that the entire Linux zone support ecosystem deliberately locks these devices out / or at best consigns them to a severely performance-penalized path, especially given the MULTIPLE statements that have been made in the NVMe ZNS WG by multiple companies regarding the use cases for which Zone Append is an absolute disaster (not my words), seems pretty darn inappropriate. -----Original Message----- From: linux-nvme [mailto:linux-nvme-bounces@lists.infradead.org] On Behalf Of Damien Le Moal Sent: Tuesday, June 16, 2020 5:36 AM To: Javier González; Matias Bjørling Cc: Jens Axboe; Niklas Cassel; Ajay Joshi; Sagi Grimberg; Keith Busch; Dmitry Fomichev; Aravind Ramesh; linux-nvme@lists.infradead.org; linux-block@vger.kernel.org; Hans Holmberg; Christoph Hellwig; Matias Bjorling Subject: Re: [PATCH 5/5] nvme: support for zoned namespaces On 2020/06/16 21:24, Javier González wrote: > On 16.06.2020 14:06, Matias Bjørling wrote: >> On 16/06/2020 14.00, Javier González wrote: >>> On 16.06.2020 13:18, Matias Bjørling wrote: >>>> On 16/06/2020 12.41, Javier González wrote: >>>>> On 16.06.2020 08:34, Keith Busch wrote: >>>>>> Add support for NVM Express Zoned Namespaces (ZNS) Command Set defined >>>>>> in NVM Express TP4053. Zoned namespaces are discovered based on their >>>>>> Command Set Identifier reported in the namespaces Namespace >>>>>> Identification Descriptor list. A successfully discovered Zoned >>>>>> Namespace will be registered with the block layer as a host managed >>>>>> zoned block device with Zone Append command support. A namespace that >>>>>> does not support append is not supported by the driver. >>>>> >>>>> Why are we enforcing the append command? Append is optional on the >>>>> current ZNS specification, so we should not make this mandatory in the >>>>> implementation. See specifics below. >>> >>>> >>>> There is already general support in the kernel for the zone append >>>> command. Feel free to submit patches to emulate the support. It is >>>> outside the scope of this patchset. >>>> >>> >>> It is fine that the kernel supports append, but the ZNS specification >>> does not impose the implementation for append, so the driver should not >>> do that either. >>> >>> ZNS SSDs that choose to leave append as a non-implemented optional >>> command should not rely on emulated SW support, specially when >>> traditional writes work very fine for a large part of current ZNS use >>> cases. >>> >>> Please, remove this virtual constraint. >> >> The Zone Append command is mandatory for zoned block devices. Please >> see https://urldefense.proofpoint.com/v2/url?u=https-3A__lwn.net_Articles_818709_&d=DwIFAw&c=JfeWlBa6VbDyTXraMENjy_b_0yKWuqQ4qY-FPhxK4x8w-TfgRBDyeV4hVQQBEgL2&r=YJM_QPk2w1CRIo5NNBXnCXGzNnmIIfG_iTRs6chBf6s&m=-fIHWuFYU2GHiTJ2FuhTBgrypPIJW0FjLUWTaK4cH9c&s=kkJ8bJpiTjKS9PoobDPHTf11agXKNUpcw5AsIEyewZk&e= for the background. > > I do not see anywhere in the block layer that append is mandatory for > zoned devices. Append is emulated on ZBC, but beyond that there is no > mandatory bits. Please explain. This is to allow a single write IO path for all types of zoned block device for higher layers, e.g file systems. The on-going re-work of btrfs zone support for instance now relies 100% on zone append being supported. That significantly simplifies the file system support and more importantly remove the need for locking around block allocation and BIO issuing, allowing to preserve a fully asynchronous write path that can include workqueues for efficient CPU usage of things like encryption and compression. Without zone append, file system would either (1) have to reject these drives that do not support zone append, or (2) implement 2 different write IO path (slower regular write and zone append). None of these options are ideal, to say the least. So the approach is: mandate zone append support for ZNS devices. To allow other ZNS drives, an emulation similar to SCSI can be implemented, with that emulation ideally combined to work for both types of drives if possible. And note that this emulation would require the drive to be operated with mq-deadline to enable zone write locking for preserving write command order. While on a HDD the performance penalty is minimal, it will likely be significant on a SSD. > >> Please submitpatches if you want to have support for ZNS devices that >> does not implement the Zone Append command. It is outside the scope >> of this patchset. > > That we will. > > > _______________________________________________ > linux-nvme mailing list > linux-nvme@lists.infradead.org > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_mailman_listinfo_linux-2Dnvme&d=DwIFAw&c=JfeWlBa6VbDyTXraMENjy_b_0yKWuqQ4qY-FPhxK4x8w-TfgRBDyeV4hVQQBEgL2&r=YJM_QPk2w1CRIo5NNBXnCXGzNnmIIfG_iTRs6chBf6s&m=-fIHWuFYU2GHiTJ2FuhTBgrypPIJW0FjLUWTaK4cH9c&s=HeBnGkcBM5OqESkW8yYYi2KtvVwbdamrbd_X5PgGKBk&e= > -- Damien Le Moal Western Digital Research _______________________________________________ linux-nvme mailing list linux-nvme@lists.infradead.org https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_mailman_listinfo_linux-2Dnvme&d=DwIFAw&c=JfeWlBa6VbDyTXraMENjy_b_0yKWuqQ4qY-FPhxK4x8w-TfgRBDyeV4hVQQBEgL2&r=YJM_QPk2w1CRIo5NNBXnCXGzNnmIIfG_iTRs6chBf6s&m=-fIHWuFYU2GHiTJ2FuhTBgrypPIJW0FjLUWTaK4cH9c&s=HeBnGkcBM5OqESkW8yYYi2KtvVwbdamrbd_X5PgGKBk&e= _______________________________________________ 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-16 13:08 UTC|newest] Thread overview: 192+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-06-15 23:34 [PATCH 0/5] nvme support for zoned namespace command set Keith Busch 2020-06-15 23:34 ` Keith Busch 2020-06-15 23:34 ` [PATCH 1/5] block: add capacity field to zone descriptors Keith Busch 2020-06-15 23:34 ` Keith Busch 2020-06-15 23:49 ` Chaitanya Kulkarni 2020-06-15 23:49 ` Chaitanya Kulkarni 2020-06-16 10:28 ` Javier González 2020-06-16 10:28 ` Javier González 2020-06-16 13:47 ` Daniel Wagner 2020-06-16 13:47 ` Daniel Wagner 2020-06-16 13:54 ` Johannes Thumshirn 2020-06-16 13:54 ` Johannes Thumshirn 2020-06-16 15:41 ` Martin K. Petersen 2020-06-16 15:41 ` Martin K. Petersen 2020-06-15 23:34 ` [PATCH 2/5] null_blk: introduce zone capacity for zoned device Keith Busch 2020-06-15 23:34 ` Keith Busch 2020-06-15 23:46 ` Chaitanya Kulkarni 2020-06-15 23:46 ` Chaitanya Kulkarni 2020-06-16 14:18 ` Daniel Wagner 2020-06-16 14:18 ` Daniel Wagner 2020-06-16 15:48 ` Martin K. Petersen 2020-06-16 15:48 ` Martin K. Petersen 2020-06-15 23:34 ` [PATCH 3/5] nvme: implement I/O Command Sets Command Set support Keith Busch 2020-06-15 23:34 ` Keith Busch 2020-06-16 10:33 ` Javier González 2020-06-16 10:33 ` Javier González 2020-06-16 17:14 ` Niklas Cassel 2020-06-16 17:14 ` Niklas Cassel 2020-06-16 15:58 ` Martin K. Petersen 2020-06-16 15:58 ` Martin K. Petersen 2020-06-16 17:01 ` Keith Busch 2020-06-16 17:01 ` Keith Busch 2020-06-17 9:50 ` Niklas Cassel 2020-06-17 9:50 ` Niklas Cassel 2020-06-16 17:06 ` Niklas Cassel 2020-06-16 17:06 ` Niklas Cassel 2020-06-17 2:01 ` Martin K. Petersen 2020-06-17 2:01 ` Martin K. Petersen 2020-06-15 23:34 ` [PATCH 4/5] nvme: support for multi-command set effects Keith Busch 2020-06-15 23:34 ` Keith Busch 2020-06-16 10:34 ` Javier González 2020-06-16 10:34 ` Javier González 2020-06-16 16:03 ` Martin K. Petersen 2020-06-16 16:03 ` Martin K. Petersen 2020-06-15 23:34 ` [PATCH 5/5] nvme: support for zoned namespaces Keith Busch 2020-06-15 23:34 ` Keith Busch 2020-06-16 10:41 ` Javier González 2020-06-16 10:41 ` Javier González 2020-06-16 11:18 ` Matias Bjørling 2020-06-16 11:18 ` Matias Bjørling 2020-06-16 12:00 ` Javier González 2020-06-16 12:00 ` Javier González 2020-06-16 12:06 ` Matias Bjørling 2020-06-16 12:06 ` Matias Bjørling 2020-06-16 12:24 ` Javier González 2020-06-16 12:24 ` Javier González 2020-06-16 12:27 ` Matias Bjørling 2020-06-16 12:27 ` Matias Bjørling 2020-06-16 12:35 ` Damien Le Moal 2020-06-16 12:35 ` Damien Le Moal [not found] ` <CGME20200616130815uscas1p1be34e5fceaa548eac31fb30790a689d4@uscas1p1.samsung.com> 2020-06-16 13:08 ` Judy Brock [this message] 2020-06-16 13:08 ` Judy Brock 2020-06-16 13:32 ` Matias Bjørling 2020-06-16 13:32 ` Matias Bjørling 2020-06-16 13:34 ` Damien Le Moal 2020-06-16 13:34 ` Damien Le Moal 2020-06-16 14:16 ` Javier González 2020-06-16 14:16 ` Javier González 2020-06-16 14:42 ` Damien Le Moal 2020-06-16 14:42 ` Damien Le Moal 2020-06-16 15:02 ` Javier González 2020-06-16 15:02 ` Javier González 2020-06-16 15:20 ` Matias Bjørling 2020-06-16 15:20 ` Matias Bjørling 2020-06-16 16:03 ` Javier González 2020-06-16 16:03 ` Javier González 2020-06-16 16:07 ` Matias Bjorling 2020-06-16 16:07 ` Matias Bjorling 2020-06-16 16:21 ` Javier González 2020-06-16 16:21 ` Javier González 2020-06-16 16:25 ` Matias Bjørling 2020-06-16 16:25 ` Matias Bjørling 2020-06-16 15:48 ` Keith Busch 2020-06-16 15:48 ` Keith Busch 2020-06-16 15:55 ` Javier González 2020-06-16 15:55 ` Javier González 2020-06-16 16:04 ` Matias Bjorling 2020-06-16 16:04 ` Matias Bjorling 2020-06-16 16:07 ` Keith Busch 2020-06-16 16:07 ` Keith Busch 2020-06-16 16:13 ` Javier González 2020-06-16 16:13 ` Javier González 2020-06-17 0:38 ` Damien Le Moal 2020-06-17 0:38 ` Damien Le Moal 2020-06-17 6:18 ` Javier González 2020-06-17 6:18 ` Javier González 2020-06-17 6:54 ` Damien Le Moal 2020-06-17 6:54 ` Damien Le Moal 2020-06-17 7:11 ` Javier González 2020-06-17 7:11 ` Javier González 2020-06-17 7:29 ` Damien Le Moal 2020-06-17 7:29 ` Damien Le Moal 2020-06-17 7:34 ` Javier González 2020-06-17 7:34 ` Javier González 2020-06-17 0:14 ` Damien Le Moal 2020-06-17 0:14 ` Damien Le Moal 2020-06-17 6:09 ` Javier González 2020-06-17 6:09 ` Javier González 2020-06-17 6:47 ` Damien Le Moal 2020-06-17 6:47 ` Damien Le Moal 2020-06-17 7:02 ` Javier González 2020-06-17 7:02 ` Javier González 2020-06-17 7:24 ` Damien Le Moal 2020-06-17 7:24 ` Damien Le Moal 2020-06-17 7:29 ` Javier González 2020-06-17 7:29 ` Javier González [not found] ` <CGME20200616123503uscas1p22ce22054a1b4152a20437b5abdd55119@uscas1p2.samsung.com> 2020-06-16 12:35 ` Judy Brock 2020-06-16 12:35 ` Judy Brock 2020-06-16 12:37 ` Damien Le Moal 2020-06-16 12:37 ` Damien Le Moal 2020-06-16 12:37 ` Matias Bjørling 2020-06-16 12:37 ` Matias Bjørling 2020-06-16 13:12 ` Judy Brock 2020-06-16 13:12 ` Judy Brock 2020-06-16 13:18 ` Judy Brock 2020-06-16 13:18 ` Judy Brock 2020-06-16 13:32 ` Judy Brock 2020-06-16 13:32 ` Judy Brock 2020-06-16 13:39 ` Damien Le Moal 2020-06-16 13:39 ` Damien Le Moal 2020-06-17 7:43 ` Christoph Hellwig 2020-06-17 7:43 ` Christoph Hellwig 2020-06-17 12:01 ` Martin K. Petersen 2020-06-17 12:01 ` Martin K. Petersen 2020-06-17 15:00 ` Javier González 2020-06-17 15:00 ` Javier González 2020-06-17 14:42 ` Javier González 2020-06-17 14:42 ` Javier González 2020-06-17 17:57 ` Matias Bjørling 2020-06-17 17:57 ` Matias Bjørling 2020-06-17 18:28 ` Javier González 2020-06-17 18:28 ` Javier González 2020-06-17 18:55 ` Matias Bjorling 2020-06-17 18:55 ` Matias Bjorling 2020-06-17 19:09 ` Javier González 2020-06-17 19:09 ` Javier González 2020-06-17 19:23 ` Matias Bjørling 2020-06-17 19:23 ` Matias Bjørling 2020-06-17 19:40 ` Javier González 2020-06-17 19:40 ` Javier González 2020-06-17 23:44 ` Heiner Litz 2020-06-17 23:44 ` Heiner Litz 2020-06-18 1:55 ` Keith Busch 2020-06-18 1:55 ` Keith Busch 2020-06-18 4:24 ` Heiner Litz 2020-06-18 4:24 ` Heiner Litz 2020-06-18 5:15 ` Damien Le Moal 2020-06-18 5:15 ` Damien Le Moal 2020-06-18 20:47 ` Heiner Litz 2020-06-18 20:47 ` Heiner Litz 2020-06-18 21:04 ` Matias Bjorling 2020-06-18 21:04 ` Matias Bjorling 2020-06-18 21:19 ` Keith Busch 2020-06-18 21:19 ` Keith Busch 2020-06-18 22:05 ` Heiner Litz 2020-06-18 22:05 ` Heiner Litz 2020-06-19 0:57 ` Damien Le Moal 2020-06-19 0:57 ` Damien Le Moal 2020-06-19 10:29 ` Matias Bjorling 2020-06-19 10:29 ` Matias Bjorling 2020-06-19 18:08 ` Heiner Litz 2020-06-19 18:08 ` Heiner Litz 2020-06-19 18:10 ` Keith Busch 2020-06-19 18:10 ` Keith Busch 2020-06-19 18:17 ` Heiner Litz 2020-06-19 18:17 ` Heiner Litz 2020-06-19 18:22 ` Keith Busch 2020-06-19 18:22 ` Keith Busch 2020-06-19 18:25 ` Matias Bjørling 2020-06-19 18:25 ` Matias Bjørling 2020-06-19 18:40 ` Heiner Litz 2020-06-19 18:40 ` Heiner Litz 2020-06-19 18:18 ` Matias Bjørling 2020-06-19 18:18 ` Matias Bjørling 2020-06-20 6:33 ` Christoph Hellwig 2020-06-20 6:33 ` Christoph Hellwig 2020-06-20 17:52 ` Heiner Litz 2020-06-20 17:52 ` Heiner Litz 2020-06-22 14:01 ` Christoph Hellwig 2022-03-02 21:11 ` Luis Chamberlain 2020-06-17 2:08 ` Martin K. Petersen 2020-06-17 2:08 ` Martin K. Petersen
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=4a97bb114ece452c80f08b96d6cbc11d@samsung.com \ --to=judy.brock@samsung.com \ --cc=Ajay.Joshi@wdc.com \ --cc=Aravind.Ramesh@wdc.com \ --cc=Damien.LeMoal@wdc.com \ --cc=Dmitry.Fomichev@wdc.com \ --cc=Hans.Holmberg@wdc.com \ --cc=Keith.Busch@wdc.com \ --cc=Matias.Bjorling@wdc.com \ --cc=Niklas.Cassel@wdc.com \ --cc=axboe@kernel.dk \ --cc=hch@lst.de \ --cc=javier@javigon.com \ --cc=linux-block@vger.kernel.org \ --cc=linux-nvme@lists.infradead.org \ --cc=mb@lightnvm.io \ --cc=sagi@grimberg.me \ /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.