4.4 regression/bisected: error message due to "block/sd: Fix device-imposed transfer length limits"
Subsystems (2)
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
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Christian" == Christian Borntraeger <[email protected]> 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
Signature · 1 line
Martin K. Petersen Oracle Linux Engineering
Quoted 6 lines · Martin K. Petersen
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Christian" == Christian Borntraeger <[email protected]> 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
Quoted 7 lines
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 blockssg_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.
Quoted 2 lines · Christian Borntraeger
Quoted 1 line · Martin K. Petersen
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Christian" == Christian Borntraeger <[email protected]> writes:
Martin,
does the data make any sense to you?
Quoted 43 lines
Quoted 5 lines
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
Quoted 7 lines
Odd.
Please provide the output of:
# sg_readcap -l /dev/sdN # sg_vpd -p bl /dev/sdNFrom 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:0x0blockssg_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 GBThis is part of a big multipath setup, if that makes a difference.
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Christian" == Christian Borntraeger <[email protected]> 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.
Signature · 1 line
Martin K. Petersen Oracle Linux Engineering