When using an Advanced Format drive connected through a SCSI-to-ATA Translation device, the physical block size reported by the kernel (in /sys/class/block/sdc/queue/physical_block_size) is 512 bytes. Whereas hdparm -I and smartctl -a do correctly show the physical block size as 4096 bytes. In my case, the drive in question is a HGST HTS541075A9E680 hard drive, connected to my PC through a USB3 HDD enclosure (USB ID 05e3:0731). While trying to find more information about this issue, I came across someone else's blog post about the same issue I'm having, which includes some in-depth analysis: http://nunix.fr/index.php/linux/7-astuces/65-too-hard-to-be-above-2tb It seems that the kernel uses less reliable means to get details about such devices than hdparm does. I'm using the kernel that's shipped in openSUSE 13.2.
Created attachment 184241 [details] Kernel log when attaching drive Attached the kernel output when the drive is connected. Note that in my case, despite the incorrect block size, the overall disk capacity is detected correctly.
Created attachment 184251 [details] hdparm -I output
Created attachment 184261 [details] smartctl -d sat -i output
Created attachment 184271 [details] lsusb -vvv output
What's the output of `sg_readcap -16 /dev/sdX`?
It is probably because of this: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/storage/scsiglue.c?h=v4.4#n217 SCSI READ CAPACITY (10) will not return "Logical blocks per physical block exponent" like READ CAPACITY (16) does: [tom@localhost ~]$ sudo sg_readcap /dev/sdc Read Capacity results: Last logical block address=468862127 (0x1bf244af), Number of blocks=468862128 Logical block length=512 bytes Hence: Device size: 240057409536 bytes, 228936.6 MiB, 240.06 GB [tom@localhost ~]$ sudo sg_readcap -16 /dev/sdc 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=468862127 (0x1bf244af), Number of logical blocks=468862128 Logical block length=512 bytes Logical blocks per physical block exponent=3 [so physical block length=4096 bytes] Lowest aligned logical block address=0 Hence: Device size: 240057409536 bytes, 228936.6 MiB, 240.06 GB So unless your adapter supports UASP (so that the uas driver will be used instead), physicial block size will be logical block size no matter what your device reports. I don't think it will really cause any trouble but if you still think it's a problem, then you should write to the linux-usb mailing list (the usb guys do not read reports on the bugzilla). It has nothing to do with the block layer (nor libata or so since it's usb device). Not to mention that your adapter may not report the exponent according to the drive behind anyway. P.S. smartctl/hdparm "works" because they use the SCSI ATA PASSTHROUGH command. It won't be an sane idea for the usb storage drivers in an OS to make use of that. Not even libata should/does.
@Dainius: Have you forwarded this bug to linux-usb mailing list?
(In reply to Tom Yan from comment #5) > What's the output of `sg_readcap -16 /dev/sdX`? The output is about the same as your output there, so it's the same problem, yes. (In reply to Pali Rohár from comment #7) > @Dainius: Have you forwarded this bug to linux-usb mailing list? No.
(In reply to Dainius Masiliūnas from comment #8) > (In reply to Tom Yan from comment #5) > > What's the output of `sg_readcap -16 /dev/sdX`? > > The output is about the same as your output there, so it's the same problem, > yes. So problem is in that code: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/storage/scsiglue.c?h=v4.4#n217 And it is needed to use READ CAPACITY (16). Other way is to use SCSI ATA PASSTHROUGH. (In reply to Dainius Masiliūnas from comment #8) > (In reply to Pali Rohár from comment #7) > > @Dainius: Have you forwarded this bug to linux-usb mailing list? > > No. Please do! This is definitely bug in kernel as it should be fixed! (e.g. better logic around READ CAPACITY (16)) (In reply to Tom Yan from comment #6) > P.S. smartctl/hdparm "works" because they use the SCSI ATA PASSTHROUGH > command. It won't be an sane idea for the usb storage drivers in an OS to > make use of that. Not even libata should/does. If READ CAPACITY (16) does not help, then SCSI ATA PASSTHROUGH is the only option here. As it is really bad if kernel provides incorrect values to userspace.