On Mon, 15 Jun 2015, Tom Yan wrote: > So I did some further investigation on the weird optimal i/o size I > got from my usb3/sata adapter/ssd, started by grep'ing the size in the > /sys/block/sdx/queue: > > [tom@localhost ~]$ grep 33553920 /sys/block/sdb/queue/* > grep: /sys/block/sdb/queue/iosched: Is a directory > /sys/block/sdb/queue/optimal_io_size:33553920 > /sys/block/sdb/queue/write_same_max_bytes:33553920 > > Because of this, for once I thought that "optimal_io_size" is somehow > set to match with "write_same_max_bytes", but later I proved that I > was wrong, and it is just sort of a coincidence. > > However, I found out that the "33553920" of "write_same_max_bytes" is > actually originated from a "max_write_same_blocks": > > [tom@localhost ~]$ grep 65535 `find /sys/devices -name max_write_same_blocks` > /sys/devices/pci0000:00/0000:00:14.0/usb4/4-2/4-2:1.0/host7/target7:0:0/7:0:0:0/scsi_disk/7:0:0:0/max_write_same_blocks:65535 > > which is set by: > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5db44863b6ebbb400c5e61d56ebe8f21ef48b1bd > > but not my hardware: > > [tom@localhost ~]$ sudo sg_inq -p 0xb0 /dev/sdb | grep same > Maximum write same length: 0x0 blocks > [tom@localhost ~]$ sudo sg_write_same --10 --num=1 /dev/sdb > Write same(10): Illegal request, invalid opcode > > While it is disabled through the variable "no_write_same" for > usb-storage (similarly for ATA and FireWire), for some reason, the uas > driver neither uses (everything of) "scsiglue" nor set the variable > itself. > > After setting the variable in uas.c, I found that the "optimal i/o > size" is still "33553920". So I keep digging. It's actually supplied > by the hardware through something called "VPD": > > http://people.redhat.com/msnitzer/docs/io-limits.txt > > But when I use `sg_inq` to look into different drives, I see that one > of them supplied an (enormous) "OPTIMAL TRANSFER LENGTH" but it's not > used to derive the "optimal_io_size" for it: > > [tom@localhost ~]$ sudo sg_inq -p 0xb0 /dev/sdc | grep "Optimal > transfer length:" > Optimal transfer length: 8388607 blocks > [tom@localhost ~]$ cat /sys/block/sdc/queue/optimal_io_size > 0 > > So I suspect something is "missing" in the uas driver again, and I am > right, which is: > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=09b6b51b0b6c1b9bb61815baf205e4d74c89ff04 > > the "skip_vpd_pages" variable makes sd_try_extended_inquiry() in > drivers/scsi/sd.c return 0 for the test in sd_revalidate_disk(), which > prevent sd_read_block_limits() and hence blk_queue_io_opt() from > running. > > So finally I solve all the mystery I got and I would like to share a > bit here. I hope it is alright. > > Also, should "no_write_same" and "skip_vpd_pages" actually be set for > uas devices as well? To understand this, you have to know how most USB mass-storage devices work. In most cases, the device contains a chip which bridges the USB bus to an internal ATA bus, which is connected to a normal ATA disk drive. Since ATA disks don't use the SCSI command set, the bridge chip "translates" SCSI commands to ATA commands and then translates the result codes back. Many of these bridge chips do not support all the relevant SCSI commands -- they can only translate a subset of the commands. And if you send one of these chips a SCSI command that it doesn't understand, in many cases the chip will crash. That's why usb-storage sets no_write_same and skip_vpd_pages. Few bridge chips implement those commands, and issuing the command to a chip which doesn't understand it is dangerous. UAS devices generally work the same way. But since the UAS transport is newer, we can hope that bridge chips for UAS are higher quality and will understand these SCSI commands and translate them correctly. Or at least, we can hope that the bridge chips won't crash when they receive these commands. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
