On 2026-06-18 22:57, Collin Funk wrote:
I believe the behavior is expected, at least after the following commit:
That commit is about writing a progress report before the fsync, but the
bug report is about the final status report, after the fsync. So I doubt
whether the commit is related to the bug.
I suspect that what we're seeing is a bug in the Linux driver (ahci,
most likely) or in your drive's firmware.
Sick Pigs, is the problem reproducible?
If you look at the system log (run "dmesg -T" or look in
/var/log/syslog) do you see any messages from the kernel? Something
containing "timeout" or "watchdog", or "reset", or "block", or "ata", or
"sda"?
The scenario I'm thinking is like this:
* dd issues an fsync system call.
* The Linux kernel issues an ATA FLUSH CACHE EXT.
* You have a DRAM-less drive, and your drive's firmware kinda panics. It
focuses on moving data out of its SLC write buffer and into its much
slower TLC main storage. While doing this, it stops responding to the
SATA bus, and holds the hardware line busy for many seconds.
* Meanwhile, the Linux ahci driver is waiting for a hardware interrupt
from the motherboard's SATA controller, using an uninterruptible polling
loop inside kernel space.
* The Linux system timer cannot fire during an uninterruptible polling loop.
* The CLOCK_MONOTONIC clock does not advance.
* 'dd' therefore thinks no time has passed.
Whether this is a bug in your drive's firmware or the ahci driver I
leave up to you. But from dd's point of view, it asked for the time and
got the wrong time from the kernel.
If the problem is reproducible, can you run the following shell commands
and let us know the output? They use 'grep' to filter out lengthy (and
possibly private) read/write traces. If the output of 'grep' is really
long, please compress it and attach the compressed file. This might help
us confirm the diagnosis.
LC_ALL=C time strace --relative-timestamps=ns -o /tmp/tr \
dd if=image.iso of=/dev/sda bs=4M conv=fsync status=progress
grep -Ev ' (read\(0|write\(1), .* = [^0]' /tmp/tr
If my guess is correct, you might be able to work around the problem by
disabling native command queueing (NCQ) for the drive
("libata.force=noncq" when booting Linux), or by telling the Linux
kernel to bypass the CPU's timers ("clocksource=hpet" or
"clocksource=acpi_pm"), or maybe even switch your I/O scheduler to be
less aggressive. These all have performance implications of course and
should be done only with some expertise.
Or you could buy a better drive, or switch to NVMe which shouldn't have
this problem. I know, expensive.
