On Mon, Sep 26, 2016 at 09:25:11AM -0700, Christoph Hellwig wrote:
> On Mon, Sep 26, 2016 at 12:19:26PM -0400, Theodore Ts'o wrote:
> > Is this a problem with the hardware, or with the UAS driver?
>
> UAS is just SCSI transport, and doesn't touch the content of command,
> so it's a very unlikely culprit. The SCSI layer intreprets it, but I
> don't really think it's doing any of this either.. Your bridge most
> likely always reports 4k sectors when using UAS for some reason.
>
> To verify this call sg_readcap on the device node for both the
> usb-storage and uas mode.
sg_readcap doesn't report the physical sector size, just the logical
block size:
# sg_readcap /dev/sdd
Read Capacity results:
Last logical block address=4000797359 (0xee7752af), Number of
blocks=4000797360
Logical block length=512 bytes
Hence:
Device size: 2048408248320 bytes, 1953514.3 MiB, 2048.41 GB
And this is the same for both with and with UAS.
So with UAS we get:
# blockdev --getpbsz /dev/sdd
4096
...even though hdparm -I reports:
Logical Sector size: 512 bytes
Physical Sector size: 512 bytes
I guess this is mostly cosmetic, since although lsblk -t reports:
# lsblk -t
NAME ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED
RQ-SIZE RA WSAME
sdd 0 4096 33553920 4096 512 1 cfq
128 128 32M
├─sdd2 0 4096 33553920 4096 512 1 cfq
128 128 32M
│ └─callcc_crypt -1 4096 0 4096 512 1
128 128 0B
nothing is actually _breaking_ since the logical sector size is still
512, and the minimum I/O and physical sector size are performance
hints.
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
