From: Christian Borntraeger <borntraeger@de.ibm.com>
To: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: linux-block@vger.kernel.org, linux-scsi@vger.kernel.org,
dm-devel@redhat.com, Steffen Maier <maier@linux.vnet.ibm.com>
Subject: Re: 4.4 regression/bisected: error message due to "block/sd: Fix device-imposed transfer length limits"
Date: Fri, 15 Jan 2016 15:48:21 +0100 [thread overview]
Message-ID: <569906B5.3040103@de.ibm.com> (raw)
In-Reply-To: <5696560D.2010105@de.ibm.com>
On 01/13/2016 02:50 PM, Christian Borntraeger wrote:
> On 01/13/2016 02:22 PM, Martin K. Petersen wrote:
>>>>>>> "Christian" == Christian Borntraeger <borntraeger@de.ibm.com> writes:
Martin,
does the data make any sense to you?
>>
>> Christian> device-mapper: table: 253:4: adding target device sdq caused
>> Christian> an alignment inconsistency: physical_block_size=4096,
>> Christian> logical_block_size=512, alignment_offset=0, start=0
>>
>> Odd.
>>
>> Please provide the output of:
>>
>> # sg_readcap -l /dev/sdN
>> # sg_vpd -p bl /dev/sdN
>>
>
> From a different system with a different disk, but the same storage server and the same error.
>
> sg_vpd -p bl /dev/sdu
> Block limits VPD page (SBC):
> Write same no zero (WSNZ): 1
> Maximum compare and write length: 0 blocks
> Optimal transfer length granularity: 128 blocks
> Maximum transfer length: 0 blocks
> Optimal transfer length: 1024 blocks
> Maximum prefetch length: 0 blocks
> Maximum unmap LBA count: 0
> Maximum unmap block descriptor count: 0
> Optimal unmap granularity: 0
> Unmap granularity alignment valid: 0
> Unmap granularity alignment: 0
> Maximum write same length: 0x0 blocks
> sg_readcap -l /dev/sdu
> Read Capacity results:
> Protection: prot_en=0, p_type=0, p_i_exponent=0
> Logical block provisioning: lbpme=0, lbprz=0
> Last logical block address=4294967295 (0xffffffff), Number of logical blocks=4294967296
> Logical block length=512 bytes
> Logical blocks per physical block exponent=3
> Lowest aligned logical block address=0
> Hence:
> Device size: 2199023255552 bytes, 2097152.0 MiB, 2199.02 GB
>
> This is part of a big multipath setup, if that makes a difference.
>
>
next prev parent reply other threads:[~2016-01-15 14:48 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-13 13:15 4.4 regression/bisected: error message due to "block/sd: Fix device-imposed transfer length limits" Christian Borntraeger
2016-01-13 13:22 ` Martin K. Petersen
2016-01-13 13:50 ` Christian Borntraeger
2016-01-15 14:48 ` Christian Borntraeger [this message]
2016-01-15 14:52 ` 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=569906B5.3040103@de.ibm.com \
--to=borntraeger@de.ibm.com \
--cc=dm-devel@redhat.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=maier@linux.vnet.ibm.com \
--cc=martin.petersen@oracle.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