linux-block.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: [PATCH v2] nvme: inherit stable pages constraint in the mpath stack device
       [not found] ` <20200401090542.GB31980@lst.de>
@ 2020-04-01 19:11   ` Sagi Grimberg
  2020-04-02  7:52     ` Christoph Hellwig
  0 siblings, 1 reply; 2+ messages in thread
From: Sagi Grimberg @ 2020-04-01 19:11 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: linux-nvme, Keith Busch, linux-block


>> @@ -1907,6 +1907,13 @@ static void __nvme_revalidate_disk(struct gendisk *disk, struct nvme_id_ns *id)
>>   	if (ns->head->disk) {
>>   		nvme_update_disk_info(ns->head->disk, ns, id);
>>   		blk_queue_stack_limits(ns->head->disk->queue, ns->queue);
>> +		if (bdi_cap_stable_pages_required(ns->queue->backing_dev_info)) {
>> +			struct backing_dev_info *info =
>> +				ns->head->disk->queue->backing_dev_info;
>> +
>> +                        info->capabilities |= BDI_CAP_STABLE_WRITES;
>> +		}
> 
> I think this needs to go into blk_queue_stack_limits instead, otherwise
> we have the same problem with other stacking drivers.

I thought about this, but the stack_limits has different variants 
(blk_stack_limits, bdev_stack_limits) but only the first takes a
request_queue...

I see that dm-table does roughly the same thing, drbd ignores it.
In general, dm is doing a whole bunch of stacking limits/capabilities
related stuff that are not involved in blk_stack_limits...

I could theoretically add a flag to queue_limits to mirror this, is
that what you are suggesting?

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [PATCH v2] nvme: inherit stable pages constraint in the mpath stack device
  2020-04-01 19:11   ` [PATCH v2] nvme: inherit stable pages constraint in the mpath stack device Sagi Grimberg
@ 2020-04-02  7:52     ` Christoph Hellwig
  0 siblings, 0 replies; 2+ messages in thread
From: Christoph Hellwig @ 2020-04-02  7:52 UTC (permalink / raw)
  To: Sagi Grimberg; +Cc: Christoph Hellwig, linux-nvme, Keith Busch, linux-block

On Wed, Apr 01, 2020 at 12:11:09PM -0700, Sagi Grimberg wrote:
>> I think this needs to go into blk_queue_stack_limits instead, otherwise
>> we have the same problem with other stacking drivers.
>
> I thought about this, but the stack_limits has different variants 
> (blk_stack_limits, bdev_stack_limits) but only the first takes a
> request_queue...
>
> I see that dm-table does roughly the same thing, drbd ignores it.
> In general, dm is doing a whole bunch of stacking limits/capabilities
> related stuff that are not involved in blk_stack_limits...
>
> I could theoretically add a flag to queue_limits to mirror this, is
> that what you are suggesting?

I guess we'll just go with your v4 patch for now and I'll see if I
can refactor this mess later..

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2020-04-02  7:52 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <20200401060625.10293-1-sagi@grimberg.me>
     [not found] ` <20200401090542.GB31980@lst.de>
2020-04-01 19:11   ` [PATCH v2] nvme: inherit stable pages constraint in the mpath stack device Sagi Grimberg
2020-04-02  7:52     ` Christoph Hellwig

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).