From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: Tom Yan <tom.ty89@gmail.com>
Cc: linux-scsi@vger.kernel.org
Subject: Re: Fwd: [PATCH 1/1] sd: do not let LBPME bit stop the VPDs speak
Date: Thu, 10 Mar 2016 21:08:02 -0500 [thread overview]
Message-ID: <yq1a8m5n4vx.fsf@sermon.lab.mkp.net> (raw)
In-Reply-To: <CAGnHSEmNreG1X78TU9RSO9UyuOPr=1urCbL-EWe7S9Q=tC8wcQ@mail.gmail.com> (Tom Yan's message of "Thu, 10 Mar 2016 16:15:57 +0800")
>>>>> "Tom" == Tom Yan <tom.ty89@gmail.com> writes:
Tom> Hmm, is it originated from: (2^32-1) - (2^32-1)%512 = 4294966784
Tom> bytes = 8388607 (512-byte) blocks = 0x7fffff
Yes.
Tom> What about SD_MAX_XFER_BLOCKS then?
It is merely there to provide a theoretical upper max for the 16 and
32-byte READ/WRITE commands. The block layer would never submit a
request that big given all the constraints we have in place (controller
segment/scatterlist/max_sectors, etc.).
The TRIM/WRITE SAME/UNMAP commands are different in that their payload
size differs from the size of the block range they act upon. So we need
to artificially constrain their limits.
--
Martin K. Petersen Oracle Linux Engineering
next prev parent reply other threads:[~2016-03-11 2:08 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-09 3:26 [PATCH 1/1] sd: do not let LBPME bit stop the VPDs speak tom.ty89
2016-03-09 3:30 ` Tom Yan
2016-03-09 3:38 ` Tom Yan
2016-03-10 2:32 ` Martin K. Petersen
[not found] ` <CAGnHSEng46jz66wkhiA73vvgfFzNx+3R4WeBLbyBrhD5UR6NBw@mail.gmail.com>
2016-03-10 8:15 ` Fwd: " Tom Yan
2016-03-11 2:08 ` Martin K. Petersen [this message]
2016-03-10 2:24 ` Martin K. Petersen
[not found] ` <CAGnHSEnHG5i3EvwmcGZU5BXobUCQa7P+j+KKNrUyoS86s7d8Gg@mail.gmail.com>
2016-03-10 8:15 ` Fwd: " Tom Yan
2016-03-11 2:02 ` Martin K. Petersen
2016-03-10 10:33 ` Tom Yan
[not found] ` <CAGnHSEkLo7sp5PUqzk74aZi6r30hVDaj2fD-i_cCHWdezZNPwA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-03-11 3:26 ` Tom Yan
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=yq1a8m5n4vx.fsf@sermon.lab.mkp.net \
--to=martin.petersen@oracle.com \
--cc=linux-scsi@vger.kernel.org \
--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