public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
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.
> 
> 


  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