Source: linux Version: 5.17.3-1 Severity: normal Tags: upstream -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
I have 2 WDC WD30EFRX-68E HDDs, one is connected 'normally' via SATA cables, the other one is build into a USB enclosure and uses UAS. The drives have the exact same same characteristics: # fdisk -l /dev/sdb Disk /dev/sdb: 2.73 TiB, 3000592982016 bytes, 5860533168 sectors Disk model: WDC WD30EFRX-68E Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Device Start End Sectors Size Type /dev/sdb1 8192 5860533134 5860524943 2.7T Linux filesystem This is the output from the drive with SATA connection and afaik the 'End' and 'Sectors' value are suboptimal. This is what I had initially on the USB connected drive: Device Start End Sectors Size Type /dev/sda1 8192 2147491839 2147483648 1T Linux filesystem Whereby the number of sectors is divisible by 8192 and thus also by 4096 (with 0 remainder ofc). However the SATA connected drive does not show any errors or warnings in dmesg when connected (on bootup), but the USB connected drive does: [19776.494284] usb 2-3: new SuperSpeed USB device number 5 using xhci_hcd [19776.524210] usb 2-3: New USB device found, idVendor=174c, idProduct=55aa, bcdDevice= 1.00 [19776.524216] usb 2-3: New USB device strings: Mfr=2, Product=3, SerialNumber=1 [19776.524218] usb 2-3: Product: USB 3.0 Device [19776.524220] usb 2-3: Manufacturer: Space keys [19776.524221] usb 2-3: SerialNumber: 000000000409 [19776.566299] scsi host9: uas [19776.567355] scsi 9:0:0:0: Direct-Access Space ke USB 3.0 Device 0 PQ: 0 ANSI: 6 [19776.567923] sd 9:0:0:0: Attached scsi generic sg1 type 0 [19776.568397] sd 9:0:0:0: [sdb] 5860533168 512-byte logical blocks: (3.00 TB/2.73 TiB) [19776.568400] sd 9:0:0:0: [sdb] 4096-byte physical blocks [19776.568475] sd 9:0:0:0: [sdb] Write Protect is off [19776.568477] sd 9:0:0:0: [sdb] Mode Sense: 43 00 00 00 [19776.568637] sd 9:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [19776.569217] sd 9:0:0:0: [sdb] Optimal transfer size 33553920 bytes not a multiple of physical block size (4096 bytes) [19776.659088] sdb: sdb1 [19776.678425] sd 9:0:0:0: [sdb] Attached SCSI disk But via USB I get this warning in dmesg: Optimal transfer size 33553920 bytes not a multiple of physical block size (4096 bytes) Looking into this issue I came across the following: http://gparted-forum.surf4.info/viewtopic.php?id=17839 which talks about misaligned partitions. Having had issue with that before (unrelated to this), I now make sure that the first partition starts at 8192 and that the total sectors is divisible by 8192 (although 4096 is likely enough). The `fdisk` program appears to nicely align partitions by default now. So AFAICT, this is NOT applicable to my situation. https://askubuntu.com/a/1237638 indicates that the warning is a sanity check by the kernel and that the kernel 'works around' the incorrectly reported optimal transfer size. But it seems to be a bug when it does so on one drive but not the other. Some data from USB drive: # lsusb -tvvv /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/8p, 10000M ID 1d6b:0003 Linux Foundation 3.0 root hub /sys/bus/usb/devices/usb2 /dev/bus/usb/002/001 |__ Port 3: Dev 5, If 0, Class=Mass Storage, Driver=uas, 5000M ID 174c:55aa ASMedia Technology Inc. ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge /sys/bus/usb/devices/2-3 /dev/bus/usb/002/005 # lsblk -t /dev/sdb NAME ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED RQ-SIZE RA WSAME sdb 0 4096 0 4096 512 1 mq-deadline 60 128 32M └─sdb1 0 4096 0 4096 512 1 mq-deadline 60 128 32M # sg_readcap -l /dev/sdb Read Capacity results: Protection: prot_en=0, p_type=0, p_i_exponent=0 Logical block provisioning: lbpme=0, lbprz=0 Last LBA=5860533167 (0x15d50a3af), Number of logical blocks=5860533168 Logical block length=512 bytes Logical blocks per physical block exponent=3 [so physical block length=4096 bytes] Lowest aligned LBA=0 Hence: Device size: 3000592982016 bytes, 2861588.5 MiB, 3000.59 GB, 3.00 TB # sg_vpd -p bl /dev/sdb Block limits VPD page (SBC): Write same non-zero (WSNZ): 0 Maximum compare and write length: 0 blocks [Command not implemented] Optimal transfer length granularity: 8 blocks Maximum transfer length: 65535 blocks Optimal transfer length: 65535 blocks Maximum prefetch transfer length: 65535 blocks Maximum unmap LBA count: 0 [Unmap command not implemented] Maximum unmap block descriptor count: 0 [Unmap command not implemented] Optimal unmap granularity: 0 blocks [not reported] Unmap granularity alignment valid: false Unmap granularity alignment: 0 [invalid] Maximum write same length: 0 blocks [not reported] Maximum atomic transfer length: 0 blocks [not reported] Atomic alignment: 0 [unaligned atomic writes permitted] Atomic transfer length granularity: 0 [no granularity requirement Maximum atomic transfer length with atomic boundary: 0 blocks [not reported] Maximum atomic boundary size: 0 blocks [can only write atomic 1 block] # sg_inq /dev/sdb standard INQUIRY: PQual=0 PDT=0 RMB=0 LU_CONG=0 hot_pluggable=0 version=0x06 [SPC-4] [AERC=0] [TrmTsk=0] NormACA=0 HiSUP=0 Resp_data_format=2 SCCS=0 ACC=0 TPGS=0 3PC=0 Protect=0 [BQue=0] EncServ=0 MultiP=0 [MChngr=0] [ACKREQQ=0] Addr16=0 [RelAdr=0] WBus16=0 Sync=0 [Linked=0] [TranDis=0] CmdQue=1 [SPI: Clocking=0x0 QAS=0 IUS=0] length=76 (0x4c) Peripheral device type: disk Vendor identification: Space ke Product identification: USB 3.0 Device Product revision level: 0 Unit serial number: 904000000000 Some data from SATA drive: # lsblk -t /dev/sdb NAME ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED RQ-SIZE RA WSAME sdb 0 4096 0 4096 512 1 mq-deadline 64 128 0B └─sdb1 0 4096 0 4096 512 1 mq-deadline 64 128 0B # sg_readcap -l /dev/sdb Read Capacity results: Protection: prot_en=0, p_type=0, p_i_exponent=0 Logical block provisioning: lbpme=0, lbprz=0 Last LBA=5860533167 (0x15d50a3af), Number of logical blocks=5860533168 Logical block length=512 bytes Logical blocks per physical block exponent=3 [so physical block length=4096 bytes] Lowest aligned LBA=0 Hence: Device size: 3000592982016 bytes, 2861588.5 MiB, 3000.59 GB, 3.00 TB # sg_vpd -p bl /dev/sdb Block limits VPD page (SBC): Write same non-zero (WSNZ): 0 Maximum compare and write length: 0 blocks [Command not implemented] Optimal transfer length granularity: 8 blocks Maximum transfer length: 0 blocks [not reported] Optimal transfer length: 0 blocks [not reported] Maximum prefetch transfer length: 0 blocks [ignored] Maximum unmap LBA count: 0 [Unmap command not implemented] Maximum unmap block descriptor count: 0 [Unmap command not implemented] Optimal unmap granularity: 0 blocks [not reported] Unmap granularity alignment valid: false Unmap granularity alignment: 0 [invalid] Maximum write same length: 0 blocks [not reported] Maximum atomic transfer length: 0 blocks [not reported] Atomic alignment: 0 [unaligned atomic writes permitted] Atomic transfer length granularity: 0 [no granularity requirement Maximum atomic transfer length with atomic boundary: 0 blocks [not reported] Maximum atomic boundary size: 0 blocks [can only write atomic 1 block] # sg_inq /dev/sdb standard INQUIRY: PQual=0 PDT=0 RMB=0 LU_CONG=0 hot_pluggable=0 version=0x05 [SPC-3] [AERC=0] [TrmTsk=0] NormACA=0 HiSUP=0 Resp_data_format=2 SCCS=0 ACC=0 TPGS=0 3PC=0 Protect=0 [BQue=0] EncServ=0 MultiP=0 [MChngr=0] [ACKREQQ=0] Addr16=0 [RelAdr=0] WBus16=0 Sync=0 [Linked=0] [TranDis=0] CmdQue=1 [SPI: Clocking=0x0 QAS=0 IUS=0] length=96 (0x60) Peripheral device type: disk Vendor identification: ATA Product identification: WDC WD30EFRX-68E Product revision level: 0A82 Unit serial number: WD-WMC4N0N4NRCA https://www.spinics.net/lists/linux-scsi/msg139591.html is where I got the various `sg_*` commands from. IIRC I also got the warning under a 5.10 kernel, but I'll verify it first before adding its version to the 'Found' category. And IIRC, I didn't get the warning when due to a 'quirks' file (/etc/modprobe.d/usb-storage-quirks.conf) another driver type was chosen (so not UAS, but I bought the enclosure exactly as that was (supposed to be) supported). While I'm not 100% sure it is a bug, it seems inconsistent to me. If it is indeed a bug, I guess it should be reported upstream, but I have no idea what upstream is in this case. If you need more info, feel free to ask. Cheers, Diederik - -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: arm64 Kernel: Linux 5.17.0-1-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCYmR5MQAKCRDXblvOeH7b bpfIAP9ZIwNaExIp14zwo6Tc7si5gZAzMk7t5xyutCgN+SeC9AD/frZBBJZ6ZqRK yzkUVxjER8KSCl/hpfB7cixZAQz9oAg= =1DgE -----END PGP SIGNATURE-----
