All of lore.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: 6+ 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-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 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.