4.4 regression/bisected: error message due to "block/sd: Fix device-imposed transfer length limits"

4.4 regression/bisected: error message due to "block/sd: Fix device-imposed transfer length limits"

[Christian Borntraeger]

Martin,

with 4.4 I get messages like

device-mapper: table: 253:4: adding target device sdq caused an alignment inconsistency: physical_block_size=4096, logical_block_size=512, alignment_offset=0, start=0

when I use device mapper multipath on a scsi disk on a FlashSystem-9840 scsi disk.
The disk has a quite interesting layout (physical block size=4k, logical=512)

blockdev --getbsz /dev/sdq
4096
blockdev --getss /dev/sdq
512
blockdev --getpbsz /dev/sdq
4096

the disks seems to work ok, though.
Any ideas?

Christian

Re: 4.4 regression/bisected: error message due to "block/sd: Fix device-imposed transfer length limits"

[Martin K. Petersen]

>>>>> "Christian" == Christian Borntraeger <borntraeger@de.ibm.com> writes:

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

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: 4.4 regression/bisected: error message due to "block/sd: Fix device-imposed transfer length limits"

[Christian Borntraeger]

On 01/13/2016 02:22 PM, Martin K. Petersen wrote:
>>>>>> "Christian" == Christian Borntraeger <borntraeger@de.ibm.com> writes:
> 
> 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.

Re: 4.4 regression/bisected: error message due to "block/sd: Fix device-imposed transfer length limits"

[Christian Borntraeger]

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.
> 
> 

Re: 4.4 regression/bisected: error message due to "block/sd: Fix device-imposed transfer length limits"

[Martin K. Petersen]

>>>>> "Christian" == Christian Borntraeger <borntraeger@de.ibm.com> writes:

Christian> does the data make any sense to you?

I will try to reproduce with scsi_debug and your parameters. I'll get to
it later today.

-- 
Martin K. Petersen	Oracle Linux Engineering