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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.