Bug 102271 - Advanced Format SAT devices show incorrect physical block size
Summary: Advanced Format SAT devices show incorrect physical block size
Status: NEW
Alias: None
Product: IO/Storage
Classification: Unclassified
Component: Block Layer (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Jens Axboe
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-08-04 16:32 UTC by Dainius Masiliūnas
Modified: 2017-01-09 17:44 UTC (History)
4 users (show)

See Also:
Kernel Version: 3.16
Subsystem:
Regression: No
Bisected commit-id:


Attachments
Kernel log when attaching drive (1013 bytes, text/plain)
2015-08-04 16:38 UTC, Dainius Masiliūnas
Details
hdparm -I output (3.77 KB, text/plain)
2015-08-04 16:41 UTC, Dainius Masiliūnas
Details
smartctl -d sat -i output (821 bytes, text/plain)
2015-08-04 16:47 UTC, Dainius Masiliūnas
Details
lsusb -vvv output (2.91 KB, text/plain)
2015-08-04 17:07 UTC, Dainius Masiliūnas
Details

Description Dainius Masiliūnas 2015-08-04 16:32:37 UTC
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.
Comment 1 Dainius Masiliūnas 2015-08-04 16:38:48 UTC
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.
Comment 2 Dainius Masiliūnas 2015-08-04 16:41:02 UTC
Created attachment 184251 [details]
hdparm -I output
Comment 3 Dainius Masiliūnas 2015-08-04 16:47:04 UTC
Created attachment 184261 [details]
smartctl -d sat -i output
Comment 4 Dainius Masiliūnas 2015-08-04 17:07:52 UTC
Created attachment 184271 [details]
lsusb -vvv output
Comment 5 Tom Yan 2016-03-12 12:26:09 UTC
What's the output of `sg_readcap -16 /dev/sdX`?
Comment 6 Tom Yan 2016-03-12 12:42:46 UTC
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.
Comment 7 Pali Rohár 2016-04-03 11:09:14 UTC
@Dainius: Have you forwarded this bug to linux-usb mailing list?
Comment 8 Dainius Masiliūnas 2016-04-03 13:06:51 UTC
(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.
Comment 9 Pali Rohár 2017-01-09 17:44:06 UTC
(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.

Note You need to log in before you can comment on or make changes to this bug.