[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1010085: marked as done (linux: Optimal transfer size 33553920 bytes not a multiple of physical block size (4096 bytes))

Your message dated Sun, 15 Jun 2025 18:11:33 +0200
with message-id <DAN8LU8TXGYV.1IC0R1R1R0ORH@cknow.org>
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 owner@bugs.debian.org
immediately.)


-- 
1010085: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010085
Debian Bug Tracking System
Contact owner@bugs.debian.org 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

Attachment: signature.asc
Description: PGP signature


--- End Message ---
Reply to: