From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: John Dorminy <jdorminy@redhat.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>,
Mike Snitzer <snitzer@redhat.com>,
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: Wed, 30 Jan 2019 21:23:09 -0500 [thread overview]
Message-ID: <yq1ftt9bm5u.fsf@oracle.com> (raw)
In-Reply-To: <CAMeeMh85T_qui=LWd0u=b_oMN5XLqowqkvLuYGBM2Ae6tS-mzg@mail.gmail.com> (John Dorminy's message of "Wed, 30 Jan 2019 09:08:50 -0500")
John,
>> So disallowing WRITE SAME unless all component devices have the same LBS
>> is the correct fix.
>
> Alternately, could possibly WRITE_SAME bios be accepted with the
> minimum sector size of the stack rather than the max, e.g. 512 in this
> example rather than 4k? They'd need to have a granularity of the
> larger sector size, though, presumabily necessitating new queue limits
> write_same_{granularity,block_size}, which might be too much work.
I don't have a problem restricting the buffer contents to be consistent
within a page. Or even change the upper layer semantics to specify the
buffer contents using a single byte (0x00..0xff).
But the issue of head and tail remains if there is a block size mismatch
so it's important that we keep scaling the logical block size up when
stacking and reject any bio that can't be honored on a 4Kn device.
> (I use WRITE_SAME to fill devices with a particular pattern in order
> to catch failures to initialize disk structures appropriately,
> personally, but it's just for convenience/speed.)
The intent was for stuff like MD to use it to initialize parity disks,
etc. But adoption has been pretty slow.
I don't have any problems keeping WRITE_SAME around if people are
actually using it. It just seemed like most active users only cared
about writing zeroes.
--
Martin K. Petersen Oracle Linux Engineering
next prev parent reply other threads:[~2019-01-31 2:23 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
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 [this message]
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=yq1ftt9bm5u.fsf@oracle.com \
--to=martin.petersen@oracle.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=snitzer@redhat.com \
--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).