From: Martin Wilck <martin.wilck@suse.com>
To: Christoph Hellwig <hch@lst.de>,
Benjamin Marzinski <bmarzins@redhat.com>,
Hannes Reinecke <hare@kernel.org>,
Mike Snitzer <snitzer@kernel.org>
Cc: Hannes Reinecke <hare@suse.de>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
James Bottomley <james.bottomley@hansenpartnership.com>,
linux-scsi@vger.kernel.org, dm-devel@lists.linux.dev
Subject: Re: [PATCH] scsi_lib: Align max_sectors to kb
Date: Fri, 19 Apr 2024 10:27:53 +0200 [thread overview]
Message-ID: <be267b46dd6bea6d82334d9d591c9a5054ff3b17.camel@suse.com> (raw)
In-Reply-To: <20240419062035.GA12480@lst.de>
(added Mike, Ben, and dm-devel)
On Fri, 2024-04-19 at 08:20 +0200, Christoph Hellwig wrote:
> On Thu, Apr 18, 2024 at 06:46:06PM +0200, Martin Wilck wrote:
> > > Why would we? It makes absolutly no sense to inherit these
> > > limits,
> > > the lower device will split anyway which is very much the point
> > > of
> > > the immutable bio_vec work.
> > >
> >
> > Sorry, I don't follow. With (request-based) dm-multipath on top of
> > SCSI, we hit the "over max size limit" condition in
> > blk_insert_cloned_request() [1], which will cause IO to fail at the
> > dm
> > level. So at least in this configuration, it's crucial that the
> > upper
> > device inherit the lower device's limits.
>
> Oh, indeed. Request based multipath is different from everyone else.
> I really wish we could spend the effort to convert it to bio based
> and remove this special case..
>
Well, it's just a matter of setting "queue_mode" in the multipath
configuration. But request-based has been the default since kernel v3.0
(f40c67f0f7e2 ("dm mpath: change to be request based")). While we
got bio-based dm-multipath back in v4.8 (76e33fe4e2c4 ("dm mpath:
reinstate bio-based support")), making it the default or even
removing request-based dm (in order to free the block layer from limit-
stacking requirements) will obviously require a broad discussion.
Mike has pointed out in 76e33fe4e2c4 that many of the original reasons
for introducing request-based dm-multipath have been obsoleted by
faster hardware and improvements in the generic block layer.
I am open for discussion on this subject, but with my distribution
maintainer hat on, I don't expect the default being changed for end
customers soon. Actually, with NVMe rising, I wonder if a major
technology switch for dm-multipath (which is effectively SCSI multipath
these days) makes sense at this point in time.
Thanks,
Martin
next parent reply other threads:[~2024-04-19 8:27 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20240418070015.27781-1-hare@kernel.org>
[not found] ` <20240418070304.GA26607@lst.de>
[not found] ` <5707dfc3-f8e2-4050-9bba-029facc32ca9@suse.de>
[not found] ` <20240418145129.GA32025@lst.de>
[not found] ` <410750a52af76fdc3bcf6265c9036037cb8141da.camel@suse.com>
[not found] ` <20240419062035.GA12480@lst.de>
2024-04-19 8:27 ` Martin Wilck [this message]
2024-04-22 7:28 ` [PATCH] scsi_lib: Align max_sectors to kb Christoph Hellwig
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=be267b46dd6bea6d82334d9d591c9a5054ff3b17.camel@suse.com \
--to=martin.wilck@suse.com \
--cc=bmarzins@redhat.com \
--cc=dm-devel@lists.linux.dev \
--cc=hare@kernel.org \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=james.bottomley@hansenpartnership.com \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=snitzer@kernel.org \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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 read-only IMAP folder(s) and NNTP newsgroup(s).