Re: ata timeout exceptions

[Damien Le Moal <dlemoal@kernel.org>]

On 11/19/25 08:05, Eyal Lebedinsky wrote:
> I still suspect the disk itself it at fault (I have a replacement synced and
> ready). >> 12:15:14+11:00 kernel: ata2.00: failed command: WRITE DMA EXT
>>> 12:15:14+11:00 kernel: ata2.00: cmd 35/00:00:00:68:4e/00:20:77:00:00/e0
>>> tag 28 dma 4194304 out res 40/00:00:00:4f:c2/00:00:00:00:00/40 Emask 0x4
>>> (timeout) 12:15:14+11:00 kernel: ata2.00: status: { DRDY } 
>>> 12:15:14+11:00 kernel: ata2: hard resetting link 12:15:15+11:00 kernel:
>>> ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300) 12:15:15+11:00
>>> kernel: ata2.00: configured for UDMA/133 12:15:15+11:00 kernel: ata2: EH
>>> complete
>> 
>> It is a 4194304 byte write that is failing, i.e. 4 MiB write.
> 
> Yes, this is the size of almost all commands. With NCQ enabled the sizes are
> very variable and often less that 1 MiB.

Yes, because there will be more requests queued in the block layer, which
increases the chances of merging sequential requests. That's why the average
command size goes up.

> 
>> This sounds very much like a recent bug report we have received: https://
>> bugzilla.kernel.org/show_bug.cgi?id=220693
>> 
>> In fact, a lot of the failing commands in that bug report is also a read 
>> or write of size 4 MiB.
>> 
>> I guess you could try reverting 459779d04ae8 ("block: Improve read ahead 
>> size for rotational devices") and see if that improves things for you 
>> (while keeping NCQ enabled).I read it. I never had I/O errors reported for
>> this disk so it looks different to me.
> 
> Regardless, I am not set up to build a kernel (I used to), and being my main
> server I hesitate to fiddle with it. I will keep this disk active and
> observe the situation.

No, reverting this commit will not do anything to the max command size that a
disk can see. But you could try this:

echo 1280 > /sys/block/sdX/queue/max_sectors_kb

to reduce the maximum command size that the disk will receive.

On the other hand, if all drives in your RAID6 array are the same and only this
drive is misbehaving, then I would be tempted to say the same you are: that the
disk is turning bad and replacing it is the best solution.



-- 
Damien Le Moal
Western Digital Research