Re: [LSF/MM ATTEND] plan to deprecate old .request_fn request-based code path?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 01/13/2016 12:39 AM, Mikulas Patocka wrote:


On Tue, 12 Jan 2016, Mike Snitzer wrote:

Hi,

I'd like to attend LSF/MM and as the subject covers I'd like to at least
participate in a discussion about plans (realistic or not) for
removing/deprecating the old .request_fn path in block core and block
drivers.

The request-based DM code (only used for multipath) has gotten more
complex to support both old .request_fn and blk-mq (and stacking
combinations: .request_fn ontop of blk-mq paths, blk-mq ontop of
.request_fn paths).  Simplifying DM core in this area would be nice.

One of the hurdles has been blk-mq doesn't yet have a scheduler.  I know
Jens had/has something in the works.  But there is also the question of
whether DM's top-level blk-mq request_queue should be trained to
leverage/stack underlying blk-mq request_queue capabilities (Keith Busch
was going to look at this aspect in the context of multipath on NVMe but
I never heard anything from Keith on that).  As of now DM multipath's
blk-mq request_queue only supports a single (virtual) hw queue.

In addition to the above topic, I'd be open to discussing Linux MD
maintainership options with others if for some reason that is still an
unresolved situation come mid April.

Thanks,
Mike

Convert multipath from request-based to bio-based and these problems in
device mapper core will disappear :-)

We have been down that road already. It doesn't work.
There is a reason why we switched to request-based multipathing.

Cheers,

Hannes
--
Dr. Hannes Reinecke		   Teamlead Storage & Networking
hare@xxxxxxx			               +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel




[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux