From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: tom.ty89@gmail.com
Cc: martin.petersen@oracle.com, shaun@tancheff.com,
linux-scsi@vger.kernel.org, linux-block@vger.kernel.org,
shaun.tancheff@seagate.com
Subject: Re: [RFC] sd: dynamically adjust SD_MAX_WS16_BLOCKS as per the actual logical block size
Date: Thu, 11 Aug 2016 23:10:37 -0400 [thread overview]
Message-ID: <yq1bn0yptqq.fsf@sermon.lab.mkp.net> (raw)
In-Reply-To: <b7f44789e0e68fa57d2e3cd059ac3a5bc6d53495.1470954520.git.tom.ty89@gmail.com> (tom's message of "Fri, 12 Aug 2016 06:29:43 +0800")
>>>>> "Tom" == tom ty89 <tom.ty89@gmail.com> writes:
Tom,
Tom> However, SD_MAX_WS16_BLOCKS is used to check values that are, for
Tom> example, orignated from Maximum Write Same Length field on the
Tom> Block Limit VPD. Such field expresses the number of blocks in terms
Tom> of the actual logical sector size of the specific drive instead of
Tom> the block size that the block layer is based on (512).
I agree the SD_MAX_WS16_BLOCKS is ugly. I think it started out as a
limit expressly set in block layer sector units and then when the
discard code got expanded it got re-purposed into being something
else. So let's get that cleaned up.
However, the CDB transfer length limit is really not the main issue
here, it's bi_size that we need to enforce.
After contemplating a bit I think it would be cleanest to add
BLK_MAX_BIO_SECTORS and clamp on that in blk_queue_max_foobar() like we
do with some of the other queue limits. Move the enforcement to block
where the actual limit originates rather than code around it in sd.
Also, please use ilog2() instead of division for things like this.
--
Martin K. Petersen Oracle Linux Engineering
next prev parent reply other threads:[~2016-08-12 3:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-11 22:29 [RFC] sd: dynamically adjust SD_MAX_WS16_BLOCKS as per the actual logical block size tom.ty89
2016-08-12 3:10 ` Martin K. Petersen [this message]
2016-08-12 4:52 ` Tom Yan
2016-08-12 20:26 ` Martin K. Petersen
2016-08-14 8:46 ` Tom Yan
2016-08-16 4:02 ` 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=yq1bn0yptqq.fsf@sermon.lab.mkp.net \
--to=martin.petersen@oracle.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=shaun.tancheff@seagate.com \
--cc=shaun@tancheff.com \
--cc=tom.ty89@gmail.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