Your message dated Sun, 15 Jun 2025 18:11:33 +0200
with message-id <[email protected]>
and subject line Re: Bug#1010085: linux: Optimal transfer size 33553920 bytes
not a multiple of physical block size (4096 bytes)
has caused the Debian Bug report #1010085,
regarding linux: Optimal transfer size 33553920 bytes not a multiple of
physical block size (4096 bytes)
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1010085: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010085
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
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-----
--- End Message ---
--- Begin Message ---
Hi,
On Sun Jun 15, 2025 at 5:16 PM CEST, Salvatore Bonaccorso wrote:
> On Mon, Apr 25, 2022 at 05:54:58PM +0200, Diederik de Haas wrote:
>> On Sunday, 24 April 2022 00:10:01 CEST Diederik de Haas wrote:
>> I feel a bit more comfortable ignoring the kernel warning, but I'm still
>> not sure whether it is a harmless msg or an actual bug.
>> If the maintainers consider this not to be a bug, feel free to close it.
>
> Looking at some older bugs, what should we do with this one (asking
> this question brings it on the list of bugs to discuss in the next
> kernel team meeting)?
I haven't looked at this issue for a long time and with a quick check, I
didn't see this kernel warning. Maybe I haven't looked at the 'right'
drives; my old servers are mostly offline nowadays. Or the issue is
fixed or no longer shown.
So, I'll close this bug. If it's still present it may actually turn up
'soon', but in that case I'll bring it directly to upstream myself.
Cheers,
Diederik
signature.asc
Description: PGP signature
--- End Message ---
