From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: Bernhard Sulzer <micraft.b@gmail.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>,
linux-scsi@vger.kernel.org
Subject: Re: Invalid optimal transfer size 33553920 accepted when physical_block_size 512
Date: Sun, 22 Mar 2020 17:06:21 -0400 [thread overview]
Message-ID: <yq1eetkrtf6.fsf@oracle.com> (raw)
In-Reply-To: <1eb896cd-2be1-4225-88d8-5ee590fe063b@gmail.com> (Bernhard Sulzer's message of "Sun, 22 Mar 2020 20:45:31 +0100")
Bernhard,
> # sg_readcap /dev/sdc
> READ CAPACITY (10) indicates device capacity too large
> now trying 16 byte cdb variant
> Read Capacity results:
> Protection: prot_en=0, p_type=0, p_i_exponent=0
> Logical block provisioning: lbpme=0, lbprz=0
> Last LBA=15628053166 (0x3a3812aae), Number of logical blocks=15628053167
> Logical block length=512 bytes
> Logical blocks per physical block exponent=3 [so physical block
> length=4096 bytes]
> Lowest aligned LBA=0
> Hence:
> Device size: 8001563221504 bytes, 7630885.3 MiB, 8001.56 GB, 8.00 TB
I sent a patch that I would like you to test. It adds some additional
sanity checking to the block limits handling. Given the VPD output you
sent earlier, I am hoping it will work around the issue.
I still can't explain how the physical block size can be unset given
that it is reported by the device and the capacity is > 0xffffffff. I
even tried to tweak scsi_debug to see if somehow the no_read_capacity_16
flag for card readers happened to be set in your case and caused us to
go down the wrong path. But no. I'm stumped.
Do you have any READ CAPACITY errors or messages in your log? There were
none in the output you sent.
--
Martin K. Petersen Oracle Linux Engineering
next prev parent reply other threads:[~2020-03-22 21:06 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-22 14:32 Invalid optimal transfer size 33553920 accepted when physical_block_size 512 Bernhard Sulzer
2020-03-22 15:45 ` Martin K. Petersen
[not found] ` <accd7d25-ee35-11b9-e49b-76e20d9550f2@gmail.com>
[not found] ` <yq1pnd4uxof.fsf@oracle.com>
2020-03-22 17:41 ` Bernhard Sulzer
[not found] ` <yq1pnd4tbxm.fsf@oracle.com>
2020-03-22 19:45 ` Bernhard Sulzer
2020-03-22 21:06 ` Martin K. Petersen [this message]
2020-03-22 21:20 ` Bernhard Sulzer
2020-03-22 21:53 ` Bernhard Sulzer
2020-03-22 22:45 ` Martin K. Petersen
2020-03-22 23:10 ` Bernhard Sulzer
2020-03-22 23:22 ` Bernhard Sulzer
2020-03-22 23:32 ` Martin K. Petersen
2020-03-22 23:40 ` Bernhard Sulzer
2020-03-23 1:41 ` Martin K. Petersen
2020-03-24 13:49 ` Bryan Gurney
2020-03-24 15:47 ` [PATCH] scsi: sd: Fix optimal I/O size for devices that change reported values Martin K. Petersen
2020-03-24 15:52 ` Invalid optimal transfer size 33553920 accepted when physical_block_size 512 Martin K. Petersen
2020-03-24 16:14 ` Bernhard Sulzer
2020-03-27 0:54 ` Martin K. Petersen
2020-03-22 20:57 ` [PATCH] scsi: sd: Optimal I/O size should be a multiple of reported granularity 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=yq1eetkrtf6.fsf@oracle.com \
--to=martin.petersen@oracle.com \
--cc=linux-scsi@vger.kernel.org \
--cc=micraft.b@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