Re: [PATCH 1/8] block: add WRITE_BG

> * non-volatile media on completion. > + * WRITE_BG Background write. This is for background activity like > + * the periodic flush and background threshold writeback > * > */ > #define RW_MASK REQ_OP_WRITE > @@ -202,6

Re: [PATCH 06/12] blk-mq: Add a kick_requeue_list argument to blk_mq_requeue_request()

On 10/27/2016 12:53 AM, Bart Van Assche wrote: > Most blk_mq_requeue_request() and blk_mq_add_to_requeue_list() calls > are followed by kicking the requeue list. Hence add an argument to > these two functions that allows to kick the requeue list. This was > proposed by Christoph Hellwig. > >

Re: [PATCH 07/12] dm: Use BLK_MQ_S_STOPPED instead of QUEUE_FLAG_STOPPED in blk-mq code

On 10/27/2016 12:54 AM, Bart Van Assche wrote: > Instead of manipulating both QUEUE_FLAG_STOPPED and BLK_MQ_S_STOPPED > in the dm start and stop queue functions, only manipulate the latter > flag. Change blk_queue_stopped() tests into blk_mq_queue_stopped(). > > Signed-off-by: Bart Van Assche

Re: A question regarding "multiple SGL"

Hi Robert, please explain your use cases that isn't handled. The one and only reason to set MSDBD to 1 is to make the code a lot simpler given that there is no real use case for supporting more. RDMA uses memory registrations to register large and possibly discontiguous data regions for a

Re: A question regarding "multiple SGL"

Hi Robert, There is no feature called "Multiple SGL in one NVMe capsule". The NVMe over Fabrics specification allows a controller to advertise how many SGL descriptors it supports using the MSDBD Identify field: "Maximum SGL Data Block Descriptors (MSDBD): This field indicates the maximum

Re: A question regarding "multiple SGL"

Hi Christoph, Thanks , got it. Could you please do me favor to let me know the background why we ONLY support " MSDBD ==1"? I am NOT trying to resist or oppose anything , I just want to know the reason. You know, it is a little wired for me, as "MSDBD ==1" does not fulfill all the use

Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra scheduler

On Thu, Oct 27, 2016 at 11:26 AM, Jan Kara wrote: > On Wed 26-10-16 10:12:38, Jens Axboe wrote: >> On 10/26/2016 10:04 AM, Paolo Valente wrote: >> > >> >>Il giorno 26 ott 2016, alle ore 17:32, Jens Axboe ha >> >>scritto: >> >> >> >>On 10/26/2016 09:29 AM,

Re: [PATCH 0/3] iopmem : A block device for PCIe memory

You do realise that local filesystems can silently change the location of file data at any point in time, so there is no such thing as a "stable mapping" of file data to block device addresses in userspace? If you want remote access to the blocks owned and controlled by a filesystem, then you

[PATCH 6/7] lightnvm: add ECC error codes

Add ECC error codes to enable the appropriate handling in the target. Signed-off-by: Javier González --- include/linux/lightnvm.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/linux/lightnvm.h b/include/linux/lightnvm.h index e3ccaff..33643ae 100644 ---

[PATCH 2/7] lightnvm: do not decide on device blocks

Device blocks should be marked by the device and considered as bad blocks by the media manager. Thus, do not make assumptions on which blocks are going to be used by the device. In doing so we might lose valid blocks from the free list. Signed-off-by: Javier González ---

[PATCH 5/7] lightnvm: export set bad block table

Bad blocks should be managed by block owners. This would be either targets for data blocks or sysblk for system blocks. In order to support this, export two functions: One to mark a block as an specific type (e.g., bad block) and another to update the bad block table on the device. Move bad

Re: [PATCH 05/12] blk-mq: Introduce blk_mq_quiesce_queue()

On 10/26/2016 10:52 PM, Hannes Reinecke wrote: Hmm. Can't say I like having to have two RCU structure for the same purpose, but I guess that can't be helped. Hello Hannes, There are two RCU structures because of BLK_MQ_F_BLOCKING. Today only the nbd driver sets that flag. If the nbd driver

Re: [PATCH 0/3] iopmem : A block device for PCIe memory

On Thu, Oct 27, 2016 at 01:22:49PM +0300, Sagi Grimberg wrote: > Christoph, did you manage to leap to the future and solve the > RDMA persistency hole? :) > > e.g. what happens with O_DSYNC in this model? Or you did > a message exchange for commits? Yes, pNFS calls this the layoutcommit. That

Re: [PATCH 05/12] blk-mq: Introduce blk_mq_quiesce_queue()

Looks good, Reviewed-by: Christoph Hellwig -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

[PATCH 4/7] lightnvm: drop reserve and release LUN callbacks

On target initialization, targets use callbacks to the media manager to configure the LUNs they use. In order to simplify the flow, drop this callbacks and manage everything internally on the media manager. By making use of the newly introduce LUN management structure, the media manager knows

[PATCH 7/7] lightnvm: rrpc: split bios of size > 256kb

rrpc cannot handle bios of size > 256kb due to NVME's 64 bit completion bitmap. If a larger bio comes, split it explicitly. Signed-off-by: Javier González --- drivers/lightnvm/rrpc.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/lightnvm/rrpc.c

[PATCH 1/7] lightnvm: enable to send hint to erase command

Erases might be subject to host hints. An example is multi-plane programming to erase blocks in parallel. Enable targets to specify this hints. Signed-off-by: Javier González --- drivers/lightnvm/core.c | 9 ++--- drivers/lightnvm/gennvm.c| 5 ++---

RE: A question regarding "multiple SGL"

> > Hi Robert, > > Hey Robert, Christoph, > > > please explain your use cases that isn't handled. The one and only > > reason to set MSDBD to 1 is to make the code a lot simpler given that > > there is no real use case for supporting more. > > > > RDMA uses memory registrations to register

[PATCH 3/7] lightnvm: manage block list on LUN owner

LUNs can be exclusively owned by a target through the media manager's reserve_lun function. In this case, the target should implement its own provisioning and manage internally the free/used/bad block list. This patch introduces a LUN management structure that can be passed on to LUN exclusive

[PATCH] null_blk: Add notes to use LightNVM

If CONFIG_NVM is disabled, loading null_block module with use_lightnvm=1 fails. But there are no messages and documents related to the failure. So the patch adds the notes to use LightNVM. Signed-off-by: Yasuaki Ishimatsu Cc: Jens Axboe ---

[PATCH 2/7] lightnvm: do not decide on device blocks

Device blocks should be marked by the device and considered as bad blocks by the media manager. Thus, do not make assumptions on which blocks are going to be used by the device. In doing so we might lose valid blocks from the free list. Signed-off-by: Javier González ---

Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra scheduler

On Thu, Oct 27, 2016 at 08:41:27PM +0100, Mark Brown wrote: > Plus the benchmarking to verify that it works well of course, especially > initially where it'll also be a new queue infrastructure as well as the > blk-mq conversion itself. It does feel like something that's going to > take at least

[PATCH 0/7] LightNVM patchset V2

V2: Rebase patches on Matias' for-next Javier González (7): lightnvm: enable to send hint to erase command lightnvm: do not decide on device blocks lightnvm: manage block list on LUN owner lightnvm: drop reserve and release LUN callbacks lightnvm: export set bad block table lightnvm:

Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra scheduler

[...] >> Instead, what I can tell, as we have been looking into converting mmc >> (which I maintains) and that is indeed a significant amount of work. >> We will need to rip out all of the mmc request management, and most >> likely we also need to extend the blkmq interface - as to be able to >>

Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra scheduler

On Thu, Oct 27, 2016 at 12:21:06PM -0600, Jens Axboe wrote: > On 10/27/2016 12:13 PM, Ulf Hansson wrote: > > I can imagine, that it's not always a straight forward "convert to blk > > mq" patch for every block device driver. > Well, I've actually done a few conversions, and it's not difficult at

[PATCH 7/7] lightnvm: rrpc: split bios of size > 256kb

rrpc cannot handle bios of size > 256kb due to NVMe using a 64 bit bitmap to signal I/O completion. If a larger bio comes, split it explicitly. Signed-off-by: Javier González --- drivers/lightnvm/rrpc.c | 6 ++ 1 file changed, 6 insertions(+) diff --git

[PATCH 6/7] lightnvm: add ECC error codes

Add ECC error codes to enable the appropriate handling in the target. Signed-off-by: Javier González --- include/linux/lightnvm.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/linux/lightnvm.h b/include/linux/lightnvm.h index e3ccaff..33643ae 100644 ---

[PATCH 3/7] lightnvm: manage block list on LUN owner

From: Javier González LUNs can be exclusively owned by a target through the media manager's reserve_lun function. In this case, the target should implement its own provisioning and manage internally the free/used/bad block list. This patch introduces a LUN management

[PATCH 4/7] lightnvm: drop reserve and release LUN callbacks

From: Javier González On target initialization, targets use callbacks to the media manager to configure the LUNs they use. In order to simplify the flow, drop this callbacks and manage everything internally on the media manager. By making use of the newly introduce LUN

[PATCH 1/7] lightnvm: enable to send hint to erase command

Erases might be subject to host hints. An example is multi-plane programming to erase blocks in parallel. Enable targets to specify this hints. Signed-off-by: Javier González --- drivers/lightnvm/core.c | 9 ++--- drivers/lightnvm/gennvm.c| 5 ++---

Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra scheduler

On 10/27/2016 01:34 PM, Ulf Hansson wrote: [...] Instead, what I can tell, as we have been looking into converting mmc (which I maintains) and that is indeed a significant amount of work. We will need to rip out all of the mmc request management, and most likely we also need to extend the

Re: [PATCH 07/12] dm: Use BLK_MQ_S_STOPPED instead of QUEUE_FLAG_STOPPED in blk-mq code

On Wed, Oct 26, 2016 at 03:54:07PM -0700, Bart Van Assche wrote: > Instead of manipulating both QUEUE_FLAG_STOPPED and BLK_MQ_S_STOPPED > in the dm start and stop queue functions, only manipulate the latter > flag. Change blk_queue_stopped() tests into blk_mq_queue_stopped(). > > Signed-off-by:

Re: [PATCH 04/12] blk-mq: Move more code into blk_mq_direct_issue_request()

Looks good: Reviewed-by: Christoph Hellwig -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 11/12] nvme: Use BLK_MQ_S_STOPPED instead of QUEUE_FLAG_STOPPED in blk-mq code

Looks good, Reviewed-by: Sagi Grimberg -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra scheduler

On 10/27/2016 08:34 AM, Grozdan wrote: On Thu, Oct 27, 2016 at 11:26 AM, Jan Kara wrote: On Wed 26-10-16 10:12:38, Jens Axboe wrote: On 10/26/2016 10:04 AM, Paolo Valente wrote: Il giorno 26 ott 2016, alle ore 17:32, Jens Axboe ha scritto: On 10/26/2016

Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra scheduler

On 10/27/2016 03:26 AM, Jan Kara wrote: On Wed 26-10-16 10:12:38, Jens Axboe wrote: On 10/26/2016 10:04 AM, Paolo Valente wrote: Il giorno 26 ott 2016, alle ore 17:32, Jens Axboe ha scritto: On 10/26/2016 09:29 AM, Christoph Hellwig wrote: On Wed, Oct 26, 2016 at

Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra scheduler

[...] > > I'm hesistant to add a new scheduler because it's very easy to add, very > difficult to get rid of. If we do add BFQ as a legacy scheduler now, > it'll take us years and years to get rid of it again. We should be > moving towards LESS moving parts in the legacy path, not more. Jens, I

Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra scheduler

On 10/27/2016 11:32 AM, Ulf Hansson wrote: [...] I'm hesistant to add a new scheduler because it's very easy to add, very difficult to get rid of. If we do add BFQ as a legacy scheduler now, it'll take us years and years to get rid of it again. We should be moving towards LESS moving parts in

Re: [PATCH 02/12] blk-mq: Introduce blk_mq_hctx_stopped()

Looks fine, Reviewed-by: Christoph Hellwig -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: A question regarding "multiple SGL"

Hi Robert, Hey Robert, Christoph, please explain your use cases that isn't handled. The one and only reason to set MSDBD to 1 is to make the code a lot simpler given that there is no real use case for supporting more. RDMA uses memory registrations to register large and possibly

Re: [PATCH 06/12] blk-mq: Add a kick_requeue_list argument to blk_mq_requeue_request()

On Wed, Oct 26, 2016 at 03:53:39PM -0700, Bart Van Assche wrote: > Most blk_mq_requeue_request() and blk_mq_add_to_requeue_list() calls > are followed by kicking the requeue list. Hence add an argument to > these two functions that allows to kick the requeue list. This was > proposed by Christoph

Re: [PATCH 02/12] blk-mq: Introduce blk_mq_hctx_stopped()

Looks fine, Reviewed-by: Sagi Grimberg -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 09/12] SRP transport: Move queuecommand() wait code to SCSI core

On Wed, Oct 26, 2016 at 03:55:00PM -0700, Bart Van Assche wrote: > Additionally, rename srp_wait_for_queuecommand() into > scsi_wait_for_queuecommand() and add a comment about the > queuecommand() call from scsi_send_eh_cmnd(). > > Signed-off-by: Bart Van Assche >

Re: [PATCH 07/12] dm: Use BLK_MQ_S_STOPPED instead of QUEUE_FLAG_STOPPED in blk-mq code

On Wed, Oct 26 2016 at 6:54pm -0400, Bart Van Assche wrote: > Instead of manipulating both QUEUE_FLAG_STOPPED and BLK_MQ_S_STOPPED > in the dm start and stop queue functions, only manipulate the latter > flag. Change blk_queue_stopped() tests into

Re: [PATCH 10/12] SRP transport, scsi-mq: Wait for .queue_rq() if necessary

On Wed, Oct 26, 2016 at 03:55:34PM -0700, Bart Van Assche wrote: > Ensure that if scsi-mq is enabled that scsi_wait_for_queuecommand() > waits until ongoing shost->hostt->queuecommand() calls have finished. > > Signed-off-by: Bart Van Assche > Reviewed-by: Christoph

Re: [PATCH 06/12] blk-mq: Add a kick_requeue_list argument to blk_mq_requeue_request()

On Wed, Oct 26, 2016 at 03:53:39PM -0700, Bart Van Assche wrote: > Most blk_mq_requeue_request() and blk_mq_add_to_requeue_list() calls > are followed by kicking the requeue list. Hence add an argument to > these two functions that allows to kick the requeue list. This was > proposed by Christoph

Re: [PATCH 10/12] SRP transport, scsi-mq: Wait for .queue_rq() if necessary

Thanks for moving it, Reviewed-by: Sagi Grimberg -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 04/12] blk-mq: Move more code into blk_mq_direct_issue_request()

Looks good, Reviewed-by: Sagi Grimberg -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 09/12] SRP transport: Move queuecommand() wait code to SCSI core

Reviewed-by: Sagi Grimberg -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 04/12] blk-mq: Move more code into blk_mq_direct_issue_request()

On Wed, Oct 26, 2016 at 03:52:35PM -0700, Bart Van Assche wrote: > Move the "hctx stopped" test and the insert request calls into > blk_mq_direct_issue_request(). Rename that function into > blk_mq_try_issue_directly() to reflect its new semantics. Pass > the hctx pointer to that function instead

Re: [PATCH 01/12] blk-mq: Do not invoke .queue_rq() for a stopped queue

On Wed, Oct 26, 2016 at 03:50:44PM -0700, Bart Van Assche wrote: > The meaning of the BLK_MQ_S_STOPPED flag is "do not call > .queue_rq()". Hence modify blk_mq_make_request() such that requests > are queued instead of issued if a queue has been stopped. > > Reported-by: Ming Lei

Re: [PATCH 04/12] blk-mq: Move more code into blk_mq_direct_issue_request()

On Wed, Oct 26, 2016 at 03:52:35PM -0700, Bart Van Assche wrote: > Move the "hctx stopped" test and the insert request calls into > blk_mq_direct_issue_request(). Rename that function into > blk_mq_try_issue_directly() to reflect its new semantics. Pass > the hctx pointer to that function instead

Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra scheduler

On Wed 26-10-16 10:12:38, Jens Axboe wrote: > On 10/26/2016 10:04 AM, Paolo Valente wrote: > > > >>Il giorno 26 ott 2016, alle ore 17:32, Jens Axboe ha > >>scritto: > >> > >>On 10/26/2016 09:29 AM, Christoph Hellwig wrote: > >>>On Wed, Oct 26, 2016 at 05:13:07PM +0200, Arnd