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=image.iso of=/dev/sda bs=4M conv=fsync status=progress 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=image.iso of=/dev/sda bs=4M conv=fsync status=none 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=direct 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–550 MB/s for consumer 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=progress - conv=fsync - coreutils 9.7 - Linux kernel 7.0.9 (Nobara) Thank you for your time.
