From: Mike Snitzer <snitzer@redhat.com>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: Jens Axboe <axboe@kernel.dk>,
Eric Wheeler <dm-devel@lists.ewheeler.net>,
Christoph Hellwig <hch@lst.de>,
dm-devel@redhat.com, johnstonj.public@codenest.com,
linux-block@vger.kernel.org
Subject: Re: dm-crypt: Fix error with too large bios
Date: Fri, 26 Aug 2016 10:05:01 -0400 [thread overview]
Message-ID: <20160826140501.GA1061@redhat.com> (raw)
In-Reply-To: <24746705-a3af-e634-e675-f2214b6cf356@kernel.dk>
On Thu, Aug 25 2016 at 4:13pm -0400,
Jens Axboe <axboe@kernel.dk> wrote:
> On 08/25/2016 12:34 PM, Mikulas Patocka wrote:
> >
> >Device mapper can't split the bio in generic_make_request - it frees the
> >md->queue->bio_split bioset, to save one kernel thread per device. Device
> >mapper uses its own splitting mechanism.
> >
> >So what is the final decision? - should device mapper split the big bio or
> >should bcache not submit big bios?
> >
> >I think splitting big bios in the device mapper is better - simply because
> >it is much less code than reworking bcache to split bios internally.
> >
> >BTW. In the device mapper, we have a layer dm-io, that was created to work
> >around bio size limitations - it accepts unlimited I/O request and splits
> >it to several bios. When bio size limitations are gone, we could simplify
> >dm-io too.
>
> The patch from Ming Lei was applied for 4.8 the other day.
See linux-block commit:
4d70dca4eadf2f block: make sure a big bio is split into at most 256 bvecs
http://git.kernel.dk/cgit/linux-block/commit/?h=for-linus&id=4d70dca4eadf2f95abe389116ac02b8439c2d16c
next prev parent reply other threads:[~2016-08-26 14:05 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-11 3:56 [PATCH] Re: dm-crypt: Fix error with too large bios Eric Wheeler
2016-08-13 17:45 ` Mikulas Patocka
2016-08-14 0:07 ` Mike Snitzer
2016-08-15 17:03 ` Mikulas Patocka
2016-08-19 0:47 ` Eric Wheeler
2016-08-25 18:34 ` Mikulas Patocka
2016-08-25 18:34 ` [dm-devel] " Mikulas Patocka
2016-08-25 20:13 ` Jens Axboe
2016-08-26 14:05 ` Mike Snitzer [this message]
2016-08-27 15:09 ` Mikulas Patocka
2016-08-29 5:22 ` Ming Lei
2016-08-29 21:57 ` Mikulas Patocka
2016-08-30 7:33 ` Ming Lei
2016-08-30 12:19 ` Mikulas Patocka
2016-08-30 20:57 ` Mike Snitzer
2016-08-30 22:27 ` Mikulas Patocka
2016-08-31 6:26 ` Milan Broz
2016-08-31 13:39 ` Mike Snitzer
2016-08-29 18:19 ` Mike Snitzer
2016-08-29 22:01 ` Mikulas Patocka
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=20160826140501.GA1061@redhat.com \
--to=snitzer@redhat.com \
--cc=axboe@kernel.dk \
--cc=dm-devel@lists.ewheeler.net \
--cc=dm-devel@redhat.com \
--cc=hch@lst.de \
--cc=johnstonj.public@codenest.com \
--cc=linux-block@vger.kernel.org \
--cc=mpatocka@redhat.com \
/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 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.