On 01/13/2016 02:22 PM, Martin K. Petersen wrote: >>>>>> "Christian" == Christian Borntraeger <borntraeger@xxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
