bug#81269: dd (coreutils 9.7): incorrect elapsed time reporting causes impossible throughput (7.9 GB/s)

Sick Pigs <[email protected]> Thu, 18 Jun 2026 20:45:17 +0100
Newsgroups gmane.comp.gnu.core-utils.bugs
Message-ID <CAKgn5nzLLZxDOTQ7Doy5yMxiZ9WA9Tf0J0QjfBh2E-1t=UXWUQ@mail.gmail.com>
Package: coreutils
Version: 9.7
Severity: normal

Dear coreutils maintainers,

I believe I have found a reproducible bug in GNU dd where the reported
elapsed time
(and therefore throughput) is incorrect, even though the actual data is
written correctly. This leads to physically impossible speed reporting
(e.g. 7.9 GB/s to a SATA SSD).

System Information:

OS:
Linux nobara-pc 7.0.9-200.nobara.fc43.x86_64 #1 SMP PREEMPT_DYNAMIC

dd version:
dd (coreutils) 9.7

Device:
/dev/sda (SATA SSD, EDILOCA ES580E 240GB)

Commands Run:

1) Write ISO to disk:
sudo dd if=3Dimage.iso of=3D/dev/sda bs=3D4M conv=3Dfsync status=3Dprogress

627+1 records in
627+1 records out
2630580224 bytes copied, 0.33473 s, 7.9 GB/s

2) Independent timing verification:
time sudo dd if=3Dimage.iso of=3D/dev/sda bs=3D4M conv=3Dfsync status=3Dnon=
e

real 0m5.782s
user 0m0.004s
sys 0m0.012s

3) Verification of correctness:
cmp image.iso /dev/sda
(no output, exit status 0)

4) Additional test:
Using oflag=3Ddirect produces the same incorrect timing behavior.

Kernel confirms write and partition table update:
GPT warnings appear for /dev/sda after write, confirming device was
modified.

Expected Behaviour:
The elapsed time reported by dd should match wall-clock time, or at least
be consistent with external timing tools like `time`. Throughput should be
consistent with actual device performance (~400=E2=80=93550 MB/s for consum=
er SATA
SSD).

Actual Behaviour:
dd reports elapsed time of ~0.33s, implying ~7.9 GB/s throughput, which is
physically impossible for the hardware. However, external timing (`time`)
shows the operation actually took ~5.8s, and the written data is correct.

Additiuonal Notes:

The issue appears to be purely in dd's internal timing/statistics
reporting, not in the actual write operation itself, which completes
correctly.
I can reproduce this consistently with:
- status=3Dprogress
- conv=3Dfsync
- coreutils 9.7
- Linux kernel 7.0.9 (Nobara)

Thank you for your time.