From: Mike Snitzer <snitzer@redhat.com>
To: John Dorminy <jdorminy@redhat.com>
Cc: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>,
axboe@kernel.dk, linux-block@vger.kernel.org,
dm-devel@redhat.com, Alasdair G Kergon <agk@redhat.com>
Subject: Re: block: Fix a WRITE SAME BUG_ON
Date: Mon, 28 Jan 2019 17:14:42 -0500 [thread overview]
Message-ID: <20190128221441.GA24102@redhat.com> (raw)
In-Reply-To: <CAMeeMh_=UVGwo-=9WtBXRmiHTXnLAswqis97bM-aiuwnzPU0QQ@mail.gmail.com>
On Sat, Jan 26 2019 at 6:17am -0500,
John Dorminy <jdorminy@redhat.com> wrote:
> Hi. I have read a bit of DM code and spent an hour reviewing this... I
> didn't get to the point of knowing what the right fix for the problem
> is, and I may have a wrong understanding, but I have two thoughts
> about the patch:
>
> I don't think this is the right solution for two reasons:
>
> In the first place, if it's an LVM-only issue, we should fix it only
> for device-mapper devices. If this is the right way to fix it,
> possibly the way to do that would be to change DM calls to
> blk_queue_max_write_same_sectors() to only set the max sectors to more
> than 0 if and only if the logical block sizes match.
There is no way this is specific to lvm (or DM). It may _seem_ that way
because lvm/dm are in the business of creating stacked devices --
whereby exposing users to blk_stack_limits().
I'll have a closer look at this issue, hopefully tomorrow, but Zhang
Xiaoxu's proposed fix looks bogus to me. Not disputing there is an
issue, just feels like a different fix is needed.
Mike
next prev parent reply other threads:[~2019-01-28 22:14 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20190125021107.4595-1-zhangxiaoxu5@huawei.com>
2019-01-26 11:17 ` [dm-devel] [v2] block: Fix a WRITE SAME BUG_ON John Dorminy
2019-01-28 5:48 ` zhangxiaoxu (A)
2019-01-28 22:14 ` Mike Snitzer [this message]
2019-01-29 4:54 ` Martin K. Petersen
2019-01-29 8:52 ` Christoph Hellwig
2019-01-30 6:50 ` zhangxiaoxu (A)
2019-01-30 14:08 ` John Dorminy
2019-01-31 0:58 ` zhangxiaoxu (A)
2019-01-31 2:23 ` Martin K. Petersen
2019-01-31 10:39 ` Christoph Hellwig
2019-01-31 19:41 ` John Dorminy
2019-02-01 7:35 ` Christoph Hellwig
2019-02-01 14:09 ` John Dorminy
2019-02-01 16:03 ` [dm-devel] " Heinz Mauelshagen
2019-02-01 16:18 ` Christoph Hellwig
2019-02-12 3:11 ` zhangxiaoxu (A)
2019-02-14 2:31 ` Martin K. Petersen
2019-02-14 9:36 ` zhangxiaoxu (A)
2019-02-18 14:10 ` zhangxiaoxu (A)
2019-02-19 23:10 ` Martin K. Petersen
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=20190128221441.GA24102@redhat.com \
--to=snitzer@redhat.com \
--cc=agk@redhat.com \
--cc=axboe@kernel.dk \
--cc=dm-devel@redhat.com \
--cc=jdorminy@redhat.com \
--cc=linux-block@vger.kernel.org \
--cc=zhangxiaoxu5@huawei.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 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).