limits for
raid10"")
Fixes: e0910c8e4f87 ("dm raid: fix discard limits for raid1 and raid10")
Cc: stable@vger,kernel.org # e0910c8e4f87 was marked for stable@
Signed-off-by: Mike Snitzer
---
drivers/md/md.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --gi
On Sat, Dec 12 2020 at 4:12am -0500,
Song Liu wrote:
> Hi Jens,
>
> Please consider pulling the following changes on top of tag
> block-5.10-2020-12-05. This is to fix raid10 data corruption [1] in 5.10-rc7.
>
> Tests run on this change:
>
> 1. md raid10: tested discard on raid10 device
On Sat, Dec 12 2020 at 3:42am -0500,
Song Liu wrote:
> Hi Mike,
>
> I am looking at the a new warning while reverting the raid10 changes:
>
> In file included from ./include/linux/kernel.h:14,
> from ./include/asm-generic/bug.h:20,
> from
On Thu, Dec 10 2020 at 11:32am -0500,
Mike Snitzer wrote:
> On Thu, Dec 10 2020 at 9:58am -0500,
> Sergei Shtepa wrote:
>
> > The 12/09/2020 16:51, Mike Snitzer wrote:
> > > On Wed, Dec 09 2020 at 8:01am -0500,
> > > Sergei Shtepa wrote:
> > &g
t;
> [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1907262/
> Cc: Matthew Ruffell
> Cc: Xiao Ni
> Cc: Mike Snitzer
> Signed-off-by: Song Liu
> ---
> drivers/md/dm-raid.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/md/dm-raid.c
t;
> [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1907262/
> Cc: Matthew Ruffell
> Cc: Xiao Ni
> Cc: Mike Snitzer
> Signed-off-by: Song Liu
If you're reverting all the MD code that enabled this DM change, then
obviously the DM change must be reverted too. But please do _no
!
Mike
Fix incorrect branching at top of blk_max_size_offset().
Mike Snitzer (1):
block: fix incorrect branching in blk_max_size_offset()
include/linux/blkdev.h
valds/linux.git:
> https://git.kernel.org/torvalds/c/b3298500b23f0b53a8d81e0d5ad98a29db71f4f0
>
> Thank you!
Hi Linus,
This is _really_ embarrassing; but I screwed up the branching at the top
of blk_max_size_offset(), here is the fix:
From: Mike Snitzer
Date: Fri, 4 Dec 2020 17:21:03
nd now frowned upon, BUG_ON(in_interrupt()) in
dm_table_event().
- Remove invalid sparse annotations from dm_prepare_ioctl() and
dm_unprepare_ioctl().
----
Mike Snitzer (4):
dm writecache: remove BUG() and fail gracefully instead
On Fri, Dec 04 2020 at 12:32P -0500,
Mike Snitzer wrote:
> On Fri, Dec 04 2020 at 11:47P -0500,
> Mike Snitzer wrote:
>
> > On Thu, Dec 03 2020 at 10:59pm -0500,
> > Ming Lei wrote:
> >
> > > On Thu, Dec 03, 2020 at 09:03:43PM -0500, Mike Snitzer wrote:
On Fri, Dec 04 2020 at 11:47P -0500,
Mike Snitzer wrote:
> On Thu, Dec 03 2020 at 10:59pm -0500,
> Ming Lei wrote:
>
> > On Thu, Dec 03, 2020 at 09:03:43PM -0500, Mike Snitzer wrote:
> > > Stacking chunk_sectors seems ill-conceived. One size-fits-all splitting
> &g
On Thu, Dec 03 2020 at 10:59pm -0500,
Ming Lei wrote:
> On Thu, Dec 03, 2020 at 09:03:43PM -0500, Mike Snitzer wrote:
> > On Thu, Dec 03 2020 at 8:12pm -0500,
> > Ming Lei wrote:
> >
> > > On Thu, Dec 03, 2020 at 09:33:59AM -0500, Mike Snitzer wrote:
> >
On Thu, Dec 03 2020 at 8:45pm -0500,
Ming Lei wrote:
> On Thu, Dec 03, 2020 at 08:27:38AM -0800, Keith Busch wrote:
> > On Thu, Dec 03, 2020 at 09:33:59AM -0500, Mike Snitzer wrote:
> > > On Wed, Dec 02 2020 at 10:26pm -0500,
> > > Ming Lei wrote:
> > >
&
On Thu, Dec 03 2020 at 8:12pm -0500,
Ming Lei wrote:
> On Thu, Dec 03, 2020 at 09:33:59AM -0500, Mike Snitzer wrote:
> > On Wed, Dec 02 2020 at 10:26pm -0500,
> > Ming Lei wrote:
> >
> > > On Tue, Dec 01, 2020 at 11:07:09AM -0500, Mike Snitzer wrote:
> >
On Thu, Dec 03 2020 at 11:27am -0500,
Keith Busch wrote:
> On Thu, Dec 03, 2020 at 09:33:59AM -0500, Mike Snitzer wrote:
> > On Wed, Dec 02 2020 at 10:26pm -0500,
> > Ming Lei wrote:
> >
> > > I understand it isn't related with correctness, because the underlyin
On Wed, Dec 02 2020 at 10:26pm -0500,
Ming Lei wrote:
> On Tue, Dec 01, 2020 at 11:07:09AM -0500, Mike Snitzer wrote:
> > commit 22ada802ede8 ("block: use lcm_not_zero() when stacking
> > chunk_sectors") broke chunk_sectors limit stacking. chunk_sectors must
> >
On Tue, Dec 01 2020 at 11:04pm -0500,
JeffleXu wrote:
> Hi Mike,
>
> What about this patch?
>
> On 11/30/20 7:33 PM, Jeffle Xu wrote:
> > It should be helpful to export sysfs of "kcryptd" workqueue in some
> > cases, such as setting specific CPU affinity of the workqueue.
> >
> > Besides,
On Wed, Dec 02 2020 at 2:10am -0500,
JeffleXu wrote:
>
>
> On 12/2/20 1:03 PM, Mike Snitzer wrote:
> > What you've done here is fairly chaotic/disruptive:
> > 1) you emailed a patch out that isn't needed or ideal, I dealt already
> >staged a DM fix in l
On Wed, Dec 02 2020 at 12:03am -0500,
Mike Snitzer wrote:
> What you've done here is fairly chaotic/disruptive:
> 1) you emailed a patch out that isn't needed or ideal, I dealt already
>staged a DM fix in linux-next for 5.10-rcX, see:
>
> https://git.kernel.org/pub/scm/l
What you've done here is fairly chaotic/disruptive:
1) you emailed a patch out that isn't needed or ideal, I dealt already
staged a DM fix in linux-next for 5.10-rcX, see:
ower-of-2")
Cc: sta...@vger.kernel.org
Reported-by: John Dorminy
Reported-by: Bruce Johnston
Signed-off-by: Mike Snitzer
---
block/blk-settings.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
v2: use gcd(), instead of min_not_zero(), as suggested by John Dorminy
diff --git a/block/
On Mon, Nov 30 2020 at 7:21pm -0500,
John Dorminy wrote:
> > If you're going to cherry pick a portion of a commit header please
> > reference the commit id and use quotes or indentation to make it clear
> > what is being referenced, etc.
> Apologies.
>
> > Quite the tangent just to setup an a
your above toy example (stacking 128K and
256K chunk_sectors):
min_not_zero = 128K
gcd = 128K
SO please explain to me why gcd() is better at setting a chunk_sectors
that ensures IO doesn't span 1280K stripesize (nevermind that
chunk_sectors has no meaningful relation to io_opt to begin with!).
M
reported but still requires your DM target to change
too. Does you DM target have one or more data device(s)? If so you
really should have it provide a .iterate_devices hook. But that aside,
here is the fix I'll be staging in linux-next shortly and that I'll be
sending to Linus by the end of t
ors.
Fixes: 22ada802ede8 ("block: use lcm_not_zero() when stacking chunk_sectors")
Cc: sta...@vger.kernel.org
Reported-by: John Dorminy
Reported-by: Bruce Johnston
Signed-off-by: Mike Snitzer
---
block/blk-settings.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --gi
On Wed, Nov 18 2020 at 4:24pm -0500,
Mikulas Patocka wrote:
>
>
> On Wed, 18 Nov 2020, Mike Snitzer wrote:
>
> > On Wed, Nov 18 2020 at 10:49am -0500,
> > Mike Snitzer wrote:
> >
> > > I don't think my suggestion will help.. given it'd still leave
On Wed, Nov 18 2020 at 10:49am -0500,
Mike Snitzer wrote:
> I don't think my suggestion will help.. given it'd still leave
> persistent_memory_claim() without a return statement.
>
> Think it worthwhile to just add a dummy 'return 0;' after the BUG().
Decided to go with this
On Tue, Nov 17 2020 at 11:31am -0500,
Mike Snitzer wrote:
> On Mon, Nov 16 2020 at 6:00pm -0500,
> Randy Dunlap wrote:
>
> > On 11/15/20 11:30 PM, Christian Borntraeger wrote:
> > >
> > >
> > > On 13.11.20 23:52, Randy Dunlap wrote:
> > >
I just staged this for 5.11, see:
https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=dm-5.11=373ce365b756bf6fec237461a0bbe65f33f201f6
I tweaked your patch header just a bit.
Thanks,
Mike
On Tue, Nov 17 2020 at 9:01pm -0500,
JeffleXu wrote:
> Hi Mike,
>
>
ence at thaw time.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Mike Snitzer
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
On Mon, Nov 16 2020 at 6:00pm -0500,
Randy Dunlap wrote:
> On 11/15/20 11:30 PM, Christian Borntraeger wrote:
> >
> >
> > On 13.11.20 23:52, Randy Dunlap wrote:
> >> Building on arch/s390/ flags this as an error, so add the
> >> __noreturn attribute modifier to prevent the build error.
> >>
>
> Signed-off-by: Christoph Hellwig
Acked-by: Mike Snitzer
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
On Tue, Nov 17 2020 at 10:51am -0500,
Christoph Hellwig wrote:
> On Tue, Nov 17, 2020 at 10:46:29AM -0500, Mike Snitzer wrote:
> > On Mon, Nov 16 2020 at 4:20pm -0500,
> > Christoph Hellwig wrote:
> >
> > > Hi Jens, Minchan and Mike,
> > >
> &g
On Mon, Nov 16 2020 at 4:20pm -0500,
Christoph Hellwig wrote:
> Hi Jens, Minchan and Mike,
>
> this series cleans up a few interactions of driver with struct
> block_device, in preparation for big changes to struct block_device
> that I plan to send soon.
Thanks, I've picked up 5 and 6 for
tian Andrzej Siewior
> Cc: dm-devel@redhat.com
> Cc: Mike Snitzer
> Cc: Alasdair Kergon
I picked this up for 5.11, thanks.
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
On Thu, Nov 12 2020 at 1:05am -0500,
JeffleXu wrote:
> Hi Jens and guys in block/io_uring mailing list, this mail contains
> some discussion abount
>
> RWF_NOWAIT, please see the following contents.
>
>
>
> On 11/11/20 11:38 PM, Mike Snitzer wrote:
> >On Tue
On Tue, Nov 10 2020 at 1:55am -0500,
Jeffle Xu wrote:
> This is one prep patch for supporting iopoll for dm device.
>
> The direct IO routine will set REQ_NOWAIT flag for REQ_HIPRI IO (that
> is, IO will do iopoll) in bio_set_polled(). Then in the IO submission
> routine, the ability of
On Wed, Nov 11 2020 at 6:45am -0500,
Colin Ian King wrote:
> Hi,
>
> Static analysis on linux-next has detected an initialized variable issue
> with the following recent commit:
>
> commit 28784347451fdbf4671ba97018f816041ba2306a
> Author: Mike Snitzer
> Date:
On Sat, Nov 07 2020 at 8:09pm -0500,
JeffleXu wrote:
>
> On 11/7/20 1:45 AM, Mike Snitzer wrote:
> >On Thu, Nov 05 2020 at 9:51pm -0500,
> >JeffleXu wrote:
> >
> >>blk-mq.c: blk_mq_submit_bio
> >>
> >> if (bio->orig)
> >>
On Thu, Nov 05 2020 at 9:51pm -0500,
JeffleXu wrote:
>
> On 11/4/20 11:08 PM, Mike Snitzer wrote:
> >>I'm doubted if this should be implemented in block layer like:
> >>
> >>```
> >>
> >>struct bio {
> &
On Thu, Nov 05 2020 at 10:49pm -0500,
JeffleXu wrote:
> Hi Mike,
>
>
> I have another question about dm, though it's irrelevant to this original
>
> mail.
>
>
> Currently abnormal IO will call blk_queue_split() and normal IO will
>
> be split considering @max_sectors/@chunk_sectos (in
On Wed, Nov 04 2020 at 1:47am -0500,
JeffleXu wrote:
>
> On 11/2/20 11:28 PM, Mike Snitzer wrote:
> >On Sun, Nov 01 2020 at 10:14pm -0500,
> >JeffleXu wrote:
> >
> >>On 10/27/20 2:53 AM, Mike Snitzer wrote:
> >>>What you detailed there isn't pro
On Tue, Nov 03 2020 at 4:23am -0500,
Jeffle Xu wrote:
> Hi Mike,
>
> Why queue_work() is unnecessary here for bio with BLK_STS_DM_REQUEUE
> returned?
>
> Thanks
> Jeffle Xu
>
> ---
> drivers/md/dm.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/md/dm.c
On Sun, Nov 01 2020 at 10:14pm -0500,
JeffleXu wrote:
>
> On 10/27/20 2:53 AM, Mike Snitzer wrote:
> >What you detailed there isn't properly modeling what it needs to.
> >A given dm_target_io could result in quite a few bios (e.g. for
> >dm-striped we clone each bio for
On Tue, Oct 27 2020 at 8:55am -0400,
Mike Snitzer wrote:
> On Thu, Oct 22 2020 at 8:27pm -0400,
> Mike Christie wrote:
>
> > This patch adds a path selector that selects paths based on a CPU to
> > path mapping the user passes in and what CPU we are executing on.
On Thu, Oct 22 2020 at 8:27pm -0400,
Mike Christie wrote:
> This patch adds a path selector that selects paths based on a CPU to
> path mapping the user passes in and what CPU we are executing on. The
> primary user for this PS is where the app is optimized to use specific
> CPUs so other PSs
On Mon, Oct 26 2020 at 7:48pm -0400,
Sasha Levin wrote:
> From: Mike Snitzer
>
> [ Upstream commit 5091cdec56faeaefa79de4b6cb3c3c55e50d1ac3 ]
>
> Using blk_max_size_offset() enables DM core's splitting to impose
> ti->max_io_len (via q->limits.chunk_sectors) and also
On Thu, Oct 22 2020 at 1:28am -0400,
JeffleXu wrote:
>
> On 10/22/20 4:39 AM, Mike Snitzer wrote:
>
> >What you've _done_ could serve as a stop-gap but I'd really rather we
> >get it properly designed from the start.
>
> Indeed I totally agree with you that the des
> >> On 16/10/2020 10:49, Mickaël Salaün wrote:
> >>> On 16/10/2020 10:29, Mickaël Salaün wrote:
> >>>>
> >>>> On 15/10/2020 18:52, Mike Snitzer wrote:
> >>>>> Can you please explain why you've decided to make this a Kconfig CON
On Wed, Oct 21, 2020 at 5:04 AM Sergei Shtepa wrote:
>
> Hello everyone! Requesting for your comments and suggestions.
>
> # blk-filter
>
> Block layer filter allows to intercept BIO requests to a block device.
>
> Interception is performed at the very beginning of the BIO request
> processing,
On Thu, Oct 22, 2020 at 11:14 AM Darrick J. Wong
wrote:
>
> On Thu, Oct 22, 2020 at 04:52:13PM +0300, Sergei Shtepa wrote:
> > The 10/22/2020 13:28, Damien Le Moal wrote:
> > > On 2020/10/22 18:43, Sergei Shtepa wrote:
> > > >
> > > > Maybe, but the problem is that I can't imagine how to
On Tue, Oct 20 2020 at 2:54am -0400,
Jeffle Xu wrote:
> Design of cookie is initially constrained as a per-bio concept. It
> dosn't work well when bio-split needed, and it is really an issue when
> adding support of iopoll for dm devices.
>
> The current algorithm implementation is simple. The
On Tue, Oct 20 2020 at 2:54am -0400,
Jeffle Xu wrote:
> This patch set adds support of iopoll for dm device.
>
> This is only an RFC patch. I'm really looking forward getting your
> feedbacks on if you're interested in supporting iopoll for dm device,
> or if there's a better design to
Hey Dan,
On Fri, Oct 16, 2020 at 6:38 PM Dan Williams wrote:
>
> On Fri, Oct 16, 2020 at 2:59 PM Nabeel Meeramohideen Mohamed
> (nmeeramohide) wrote:
>
> > (5) Representing an mpool as a /dev/mpool/ device file provides
> > a
> > convenient mechanism for controlling access to and managing the
raid can efficiently handle large discards.
- A couple small cleanups across various targets.
Huaisheng Ye (1):
dm thin metadata: Remove unused local variable when create thin and snap
Mike Snitzer (17):
dm table: stack
On Mon, Sep 28 2020 at 12:03P -0400,
Mike Snitzer wrote:
> On Sun, Sep 27 2020 at 8:04am -0400,
> Jeffle Xu wrote:
>
> > Hi Mike, would you mind further expalin why bio processed by dm_wq_work()
> > always gets a previous ->submit_bio. Considering
On Sun, Sep 27 2020 at 8:04am -0400,
Jeffle Xu wrote:
> Hi Mike, would you mind further expalin why bio processed by dm_wq_work()
> always gets a previous ->submit_bio. Considering the following call graph:
>
> ->submit_bio, that is, dm_submit_bio
> DMF_BLOCK_IO_FOR_SUSPEND set, thus
On Thu, Sep 24 2020 at 9:09pm -0400,
Damien Le Moal wrote:
> On 2020/09/25 4:14, Sudhakar Panneerselvam wrote:
> >>
> >> On Thu, 24 Sep 2020, Sudhakar Panneerselvam wrote:
> >>
> By copying it to a temporary aligned buffer and issuing I/O on this
> buffer.
> >>>
> >>> I don't like
On Fri, Sep 25 2020 at 8:04am -0400,
Mikulas Patocka wrote:
>
>
> On Thu, 24 Sep 2020, Mike Snitzer wrote:
>
> > On Thu, Sep 24 2020 at 2:12pm -0400,
> > Mikulas Patocka wrote:
> >
> > >
> > >
> > > On Thu, 24 Sep 2020, Mikulas P
On Thu, Sep 24 2020 at 2:56pm -0400,
John Dorminy wrote:
> On Thu, Sep 24, 2020 at 1:24 PM John Dorminy wrote:
> >
> > I am impressed at how much I read wrong...
> >
> > On Thu, Sep 24, 2020 at 1:00 PM Mike Snitzer wrote:
> > >
> > > On Thu, Sep
On Thu, Sep 24 2020 at 2:12pm -0400,
Mikulas Patocka wrote:
>
>
> On Thu, 24 Sep 2020, Mikulas Patocka wrote:
>
> >
> >
> > On Thu, 24 Sep 2020, Mike Snitzer wrote:
> >
> > > WAIT... Could it be that raid_io_hints _really_ meant
On Thu, Sep 24 2020 at 12:45pm -0400,
John Dorminy wrote:
> I don't understand how this works...
>
> Can chunk_size_bytes be 0? If not, how is discard_granularity being set to 0?
Yeah, I had same question.. see the reply I just sent in this thread:
On Thu, Sep 24 2020 at 12:26pm -0400,
Mikulas Patocka wrote:
> This patch fixes a warning WARN_ON_ONCE(!q->limits.discard_granularity).
> The reason is that the function raid_io_hints overwrote
> limits->discard_granularity with zero. We need to properly stack the
> limits instead of overwriting
On Thu, Sep 24 2020 at 11:45am -0400,
Eric Biggers wrote:
> On Thu, Sep 24, 2020 at 09:46:49AM -0400, Mike Snitzer wrote:
> > > > Can you help me better understand the expected consumer of this code?
> > > > If you have something _real_ please be explicit. It makes ju
h Hellwig
> Acked-by: Coly Li
> Reviewed-by: Johannes Thumshirn
Thanks for adding blk_queue_update_readahead()
Reviewed-by: Mike Snitzer
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
On Thu, Sep 24 2020 at 10:34am -0400,
Mikulas Patocka wrote:
> Hi Mike
>
> Could you send this to Linus before v5.9 is released?
>
> Mikulas
>
>
>
> From: Mikulas Patocka
>
> If q->limits.discard_granularity is zero, the block core will warn in
> __blkdev_issue_discard. This patch sets it
On Thu, Sep 24 2020 at 3:38am -0400,
Satya Tangirala wrote:
> On Wed, Sep 23, 2020 at 09:21:03PM -0400, Mike Snitzer wrote:
> > On Wed, Sep 09 2020 at 7:44pm -0400,
> > Satya Tangirala wrote:
> >
> > > From: Eric Biggers
> > >
> > > U
On Thu, Sep 24 2020 at 3:17am -0400,
Satya Tangirala wrote:
> On Wed, Sep 23, 2020 at 09:14:39PM -0400, Mike Snitzer wrote:
> > On Mon, Sep 21 2020 at 8:32pm -0400,
> > Eric Biggers wrote:
> >
> > > On Wed, Sep 09, 2020 at 11:44:21PM +, Satya Tangirala wro
On Thu, Sep 24 2020 at 3:48am -0400,
Satya Tangirala wrote:
> On Wed, Sep 23, 2020 at 09:21:03PM -0400, Mike Snitzer wrote:
> > On Wed, Sep 09 2020 at 7:44pm -0400,
> > Satya Tangirala wrote:
> >
> > > From: Eric Biggers
> > >
> > > U
You've clearly done a nice job with these changes. Looks clean.
BUT, I'm struggling to just accept that dm-crypt needs to go to these
extra lengths purely because of one bad apple usecase.
These alignment constraints aren't new. Are there other portions of
Linux's crypto subsystem that needed
On Wed, Sep 09 2020 at 7:44pm -0400,
Satya Tangirala wrote:
> From: Eric Biggers
>
> Update the device-mapper core to support exposing the inline crypto
> support of the underlying device(s) through the device-mapper device.
>
> This works by creating a "passthrough keyslot manager" for the
On Mon, Sep 21 2020 at 8:32pm -0400,
Eric Biggers wrote:
> On Wed, Sep 09, 2020 at 11:44:21PM +, Satya Tangirala wrote:
> > From: Eric Biggers
> >
> > Update the device-mapper core to support exposing the inline crypto
> > support of the underlying device(s) through the device-mapper
uggested-by: Satya Tangirala
> Signed-off-by: Eric Biggers
Reviewed-by: Mike Snitzer
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
rypt_clone() able to fail, analogous to bio_integrity_clone().
>
> Reported-by: Miaohe Lin
> Cc: Satya Tangirala
> Signed-off-by: Eric Biggers
Reviewed-by: Mike Snitzer
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
On Thu, Jun 25 2020 at 7:31am -0400,
Matthew Wilcox (Oracle) wrote:
> Similar to memalloc_noio() and memalloc_nofs(), memalloc_nowait()
> guarantees we will not sleep to reclaim memory. Use it to simplify
> dm-bufio's allocations.
>
> Signed-off-by: Matthew Wilcox (Oracle)
> ---
>
-by: Konstantin Khlebnikov
Suggested-by: Christoph Hellwig
Signed-off-by: Mike Snitzer
---
block/blk-core.c | 4 ++--
include/linux/blkdev.h | 7 +--
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/block/blk-core.c b/block/blk-core.c
index ca3f0f00c943..e3adfa135a20 100644
-by: Mike Snitzer
---
drivers/md/dm-linear.c| 5 +++--
drivers/md/dm-table.c | 32
drivers/md/dm.c | 4 +++-
include/linux/device-mapper.h | 6 ++
4 files changed, 44 insertions(+), 3 deletions(-)
diff --git a/drivers/md/dm
and enable it for linear target
Mike Snitzer (1):
block: add QUEUE_FLAG_NOWAIT
block/blk-core.c | 4 ++--
drivers/md/dm-linear.c| 5 +++--
drivers/md/dm-table.c | 32
drivers/md/dm.c | 4 +++-
include/linux/blkdev.h
on updates for features added during 5.9 merge.
----
Mike Snitzer (2):
dm: fix bio splitting and its bio completion order for regular IO
dm: fix comment in dm_process_bio()
Milan Broz (2):
dm crypt: document new no_workqueue flag
-by: Mike Snitzer
Reviewed-by: Ming Lei
---
block/blk-settings.c | 10 --
include/linux/blkdev.h | 12 +---
2 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/block/blk-settings.c b/block/blk-settings.c
index b2e1a929a6db..5ea3de48afba 100644
--- a/block/blk-settings.c
to switch to using blk_max_size_offset() in
Patch 6.
Patches 5 and 6 just show how DM will be enhanced for 5.10 once
patches 3 and 4 land in the block tree.
Mike Snitzer (6):
dm: fix bio splitting and its bio completion order for regular IO
dm: fix comment in dm_process_bio()
block: use
Using blk_max_size_offset() enables DM core's splitting to impose
ti->max_io_len (via q->limits.chunk_sectors) and also fallback to
respecting q->limits.max_sectors if chunk_sectors isn't set.
Signed-off-by: Mike Snitzer
---
drivers/md/dm.c | 20
1 file c
If target set ti->max_io_len it must be used when stacking
DM device's queue_limits to establish a 'chunk_sectors' that is
compatible with the IO stack.
By using lcm_not_zero() care is taken to avoid blindly overriding the
chunk_sectors limit stacked up by blk_stack_limits().
Signed-off-by: M
Refer to the correct function (->submit_bio instead of ->queue_bio).
Also, add details about why using blk_queue_split() isn't needed for
dm_wq_work()'s call to dm_process_bio().
Fixes: c62b37d96b6eb ("block: move ->make_request_fn to struct
block_device_operations")
Signed-o
d.
Fixes: 120c9257f5f1 ("Revert "dm: always call blk_queue_split() in
dm_process_bio()"")
Cc: sta...@vger.kernel.org # 5.0+, requires custom backport due to 5.9 changes
Reported-by: Ming Lei
Signed-off-by: Mike Snitzer
---
drivers/md/dm.c | 23 ++-
1 file
'
then it is a bug in the driver and the device should be flagged as
'misaligned'.
Signed-off-by: Mike Snitzer
Reviewed-by: Ming Lei
---
block/blk-settings.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/block/blk-settings.c b/block/blk-settings.c
index
On Tue, Sep 15 2020 at 9:48pm -0400,
Ming Lei wrote:
> On Tue, Sep 15, 2020 at 09:28:14PM -0400, Mike Snitzer wrote:
> > On Tue, Sep 15 2020 at 9:08pm -0400,
> > Ming Lei wrote:
> >
> > > On Tue, Sep 15, 2020 at 01:23:57PM -0400, Mike Snitzer wrote:
> &
On Tue, Sep 15 2020 at 9:08pm -0400,
Ming Lei wrote:
> On Tue, Sep 15, 2020 at 01:23:57PM -0400, Mike Snitzer wrote:
> > blk_queue_split() has become compulsory from .submit_bio -- regardless
> > of whether it is recursing. Update DM core to always call
>
'
then it is a bug in the driver and the device should be flagged as
'misaligned'.
Signed-off-by: Mike Snitzer
Reviewed-by: Ming Lei
---
block/blk-settings.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/block/blk-settings.c b/block/blk-settings.c
index
blk_queue_split() has become compulsory from .submit_bio -- regardless
of whether it is recursing. Update DM core to always call
blk_queue_split().
dm_queue_split() is removed because __split_and_process_bio() handles
splitting as needed.
Signed-off-by: Mike Snitzer
---
drivers/md/dm.c | 45
If target set ti->max_io_len it must be used when stacking
DM device's queue_limits to establish a 'chunk_sectors' that is
compatible with the IO stack.
By using lcm_not_zero() care is taken to avoid blindly overriding the
chunk_sectors limit stacked up by blk_stack_limits().
Signed-off-by: M
It is possible for a block device to use a non power-of-2 for chunk
size which results in a full-stripe size that is also a non
power-of-2.
Update blk_queue_chunk_sectors() and blk_max_size_offset() to
accommodate drivers that need a non power-of-2 chunk_sectors.
Signed-off-by: Mike Snitzer
will be
updated to use chunk_sectors.
Mike Snitzer (4):
block: use lcm_not_zero() when stacking chunk_sectors
block: allow 'chunk_sectors' to be non-power-of-2
dm table: stack 'chunk_sectors' limit to account for target-specific splitting
dm: unconditionally call blk_queue_split() in dm_process_bio
On Mon, Sep 14 2020 at 9:33pm -0400,
Mike Snitzer wrote:
> On Thu, Sep 10 2020 at 3:29pm -0400,
> Vijayendra Suman wrote:
>
> > Hello Mike,
> >
> > I checked with upstream, performance measurement is similar and
> > s
On Thu, Sep 10 2020 at 3:29pm -0400,
Vijayendra Suman wrote:
> Hello Mike,
>
> I checked with upstream, performance measurement is similar and
> shows performance improvement when
> 120c9257f5f19e5d1e87efcbb5531b7cd81b7d74 is reverted.
>
> On 9/10/2020 7:54 PM, Mike Snit
On Sun, Sep 13 2020 at 8:43pm -0400,
Damien Le Moal wrote:
> On 2020/09/12 22:53, Ming Lei wrote:
> > On Fri, Sep 11, 2020 at 05:53:36PM -0400, Mike Snitzer wrote:
> >> blk_queue_get_max_sectors() has been trained for REQ_OP_WRITE_SAME and
> >> REQ_OP_WRITE_ZEROES
It is possible for a block device to use a non power-of-2 for chunk
size which results in a full-stripe size that is also a non
power-of-2.
Update blk_queue_chunk_sectors() and blk_max_size_offset() to
accommodate drivers that need a non power-of-2 chunk_sectors.
Signed-off-by: Mike Snitzer
-by: Mike Snitzer
---
include/linux/blkdev.h | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index bb5636cc17b9..453a3d735d66 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -1070,17 +1070,24
'
then it is a bug in the driver and the device should be flagged as
'misaligned'.
Signed-off-by: Mike Snitzer
---
block/blk-settings.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/block/blk-settings.c b/block/blk-settings.c
index 76a7e03bcd6c..b09642d5f15e
rs);
Won't be perfect for some stacked devices (given it'll constrain
chunk_sectors to be less optimal as the IO limits are stacked) but it
should be an improvment -- and hopefully fix this pgbench regression.
Thanks,
Mike
Mike Snitzer (3):
block: fix blk_rq_get_max_sectors() to flow more c
701 - 800 of 2007 matches
Mail list logo
