Collin Funk <collin.funk1@HIDDEN>
to control <at> debbugs.gnu.org.
Full text available.
Received: (at 81269) by debbugs.gnu.org; 19 Jun 2026 07:54:54 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 19 03:54:54 2026
Received: from localhost ([127.0.0.1]:49709 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1waU3y-0000gu-5g
for submit <at> debbugs.gnu.org; Fri, 19 Jun 2026 03:54:54 -0400
Received: from mail.cs.ucla.edu ([131.179.128.66]:51142)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eggert@HIDDEN>)
id 1waU3v-0000gc-OY
for 81269 <at> debbugs.gnu.org; Fri, 19 Jun 2026 03:54:52 -0400
Received: from localhost (localhost [127.0.0.1])
by mail.cs.ucla.edu (Postfix) with ESMTP id 3E0C93C008EF2;
Fri, 19 Jun 2026 00:54:45 -0700 (PDT)
Received: from mail.cs.ucla.edu ([127.0.0.1])
by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10032) with ESMTP
id CNH2cUkAI49p; Fri, 19 Jun 2026 00:54:45 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
by mail.cs.ucla.edu (Postfix) with ESMTP id 1553A3C008EF3;
Fri, 19 Jun 2026 00:54:45 -0700 (PDT)
DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu 1553A3C008EF3
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu;
s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1781855685;
bh=A3Fd46KPkW8VnfDJzPpx4c1Cyzomrn101ii/MGV1a3w=;
h=Message-ID:Date:MIME-Version:To:From;
b=X/YZQqpDzKEHlv2gIk49xLjIDFW8nwSc6wdOGCUPivYkUFsc11U++7ebdSSZHwG+P
C+c04GSUZs3kX6GU3s20awQIWrVux2s5sZrH2eiQETG4lf+5XbAQryI3tyztWeGi/r
LxqpMk/ZomZlcoo1mQX8j3hdS5tn+FYOAkT84nx92gDMk8EvfFRkjhGkWjv7ItBq0h
+z0hfqa+rSX94go0Ub8uWFL5AKYWppumZY2HyXbk4k0g2I2W+2AV7uISBla0I7FQv/
6NFYdxj/0SIz8MCufMW2chJw8SN5bcdzDcywu3FGV8juVPIqm75+AQwvZPPy1eA7cs
rsyd3QZ0fEtZw==
X-Virus-Scanned: amavis at mail.cs.ucla.edu
Received: from mail.cs.ucla.edu ([127.0.0.1])
by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10026) with ESMTP
id b-M_ImQEsHmo; Fri, 19 Jun 2026 00:54:44 -0700 (PDT)
Received: from penguin.cs.ucla.edu
(47-154-25-11.fdr01.snmn.ca.ip.frontiernet.net [47.154.25.11])
by mail.cs.ucla.edu (Postfix) with ESMTPSA id D9C2C3C008EF2;
Fri, 19 Jun 2026 00:54:44 -0700 (PDT)
Message-ID: <1b5fbb34-8bd0-4d53-9e65-f85b91f2d570@HIDDEN>
Date: Fri, 19 Jun 2026 00:54:44 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: bug#81269: dd (coreutils 9.7): incorrect elapsed time reporting
causes impossible throughput (7.9 GB/s)
To: Collin Funk <collin.funk1@HIDDEN>, Sick Pigs <sickpigs789@HIDDEN>
References: <CAKgn5nzLLZxDOTQ7Doy5yMxiZ9WA9Tf0J0QjfBh2E-1t=UXWUQ@HIDDEN>
<87h5mz6pi2.fsf@HIDDEN>
Content-Language: en-US
From: Paul Eggert <eggert@HIDDEN>
Organization: UCLA Computer Science Department
In-Reply-To: <87h5mz6pi2.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 81269
Cc: 81269 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
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.
bug-coreutils@HIDDEN:bug#81269; Package coreutils.
Full text available.
Received: (at 81269) by debbugs.gnu.org; 19 Jun 2026 05:58:08 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 19 01:58:08 2026
Received: from localhost ([127.0.0.1]:48935 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1waSEy-0002np-6T
for submit <at> debbugs.gnu.org; Fri, 19 Jun 2026 01:58:08 -0400
Received: from mail-dy1-x132f.google.com ([2607:f8b0:4864:20::132f]:60806)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <collin.funk1@HIDDEN>)
id 1waSEv-0002nK-EZ
for 81269 <at> debbugs.gnu.org; Fri, 19 Jun 2026 01:58:06 -0400
Received: by mail-dy1-x132f.google.com with SMTP id
5a478bee46e88-30bc871ecdfso2267942eec.1
for <81269 <at> debbugs.gnu.org>; Thu, 18 Jun 2026 22:58:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20251104; t=1781848679; x=1782453479; darn=debbugs.gnu.org;
h=content-transfer-encoding:mime-version:user-agent:message-id:date
:references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date
:message-id:reply-to;
bh=GYt0lBbHtH64dL/WLM2uFAP5sc38csaYXZTMUA/alzg=;
b=Kn4akH8qrDk4SJapIf9JOJyb1/hQSon2RXJdHAncE8snuAoP3iyMjiNNGYPfFXYmgG
Z2k8AU057nSMi6FhTrQx4Nq2dpXxMrBNI4FOtkEYSAdhmlYi2hmixBNO444Qg+VQIYKl
cdoIA/Hbbwcdwik7pHEAvJ5vJ4La/tN1q8xfiOoETdEXRcdQf948XBjOC+lDimxSt5MO
9Vj4ibhHugDuvGw96oF8oNeN9Y4AORpccPujftrJbCKahdyC9GM3axC6VbS8xjUiKe/1
hO7BTwfBufVGbADq9fA1vwn/RDQQFnVl1jjwk0oaHkepzMhIvKQOvBR+snY6P9/CcLWk
cAKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20251104; t=1781848679; x=1782453479;
h=content-transfer-encoding:mime-version:user-agent:message-id:date
:references:in-reply-to:subject:cc:to:from:x-gm-gg
:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
bh=GYt0lBbHtH64dL/WLM2uFAP5sc38csaYXZTMUA/alzg=;
b=lcrgzwnGuDSSIst+dFn6JV3L1PUXdiTwVc7V5298IYBWfwYjANZ8TfNMekFFcsKUOc
wT7DAq2sMbilLqqQ/JL71TIDdvZN1R8FuXpR8oM50su8DzeGtqGjnfJ9v8n5rNf2ZF9O
MlMl5JEviEbIZDZjzxptD3+SV2ex4BmZBrXBBb8+ZGqfjHCBAX/f/iTkvO3QM5Ma0Xb8
IubHijWzRRpcPfDBKPD4u45hu9fYvRYh1h7f+9ryQJNvSXNCGI7tfQ+GbzNhUO+MIl3s
uReqPivDYFrpR/rQuo06kk/fRJO1M4Mq7ZGgYCa4ZoxmDr2B6cLY4HMewfbT5buxk041
0Gsg==
X-Gm-Message-State: AOJu0Yz/cH47RB5xxG+xsw7jn2y7bgFBxtRMJFj9o7Ny+Fi30Wyy5e4H
wJrqeCMAeCrKGO9IkJ3OPuR7HuwzQ3THbkWzWvJQ9+/QXYsMoK4oEist
X-Gm-Gg: AfdE7cl3WEHDyz4Musq4ST1TDO5048y6zzZWqnnkix5tGgGAeEAcdifTWb4TPf2q2Y7
Wvft0PBbkPQr4MnXcJY+/+eLfIwzH4U2NKQkNVJ2QsVbQsbBszdym4IcU5DYZ96JuzeqUl0Jqa2
axcq4RGOtEr9xeVSpBq5T/CpG/ef8zKTd0V8bA+0565QZRy/B+N9qt3drQtFsGe9IvRWtbn4GJ+
f/zSBOQkHL3bHtS8shaXAMdr7LRPEJSK60Gutaa6Dkjvg24Iq5frjiUQPv/VwLRqiBjMd6zDZNg
ePNWTJxyj7ENuOZcO7ONp8MkEGIQBd358Ybhb+mGfDIsn7+2qGOg6GE6/KpnjkvtTgi+mu1yNff
xjCDxn/ly4sxZvpvBHAYZET+URQTG0rde7ol3aErA+5E5yeFULuAQHlpEF1zB8Tun0979zw==
X-Received: by 2002:a05:693c:65cb:b0:30c:1147:ccc3 with SMTP id
5a478bee46e88-30c1147cfc5mr106166eec.33.1781848679015;
Thu, 18 Jun 2026 22:57:59 -0700 (PDT)
Received: from fedora ([2601:646:8081:3770::33a9])
by smtp.gmail.com with ESMTPSA id
5a478bee46e88-30c06705d1esm1499827eec.7.2026.06.18.22.57.58
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Thu, 18 Jun 2026 22:57:58 -0700 (PDT)
From: Collin Funk <collin.funk1@HIDDEN>
To: Sick Pigs <sickpigs789@HIDDEN>
Subject: Re: bug#81269: dd (coreutils 9.7): incorrect elapsed time reporting
causes impossible throughput (7.9 GB/s)
In-Reply-To: <CAKgn5nzLLZxDOTQ7Doy5yMxiZ9WA9Tf0J0QjfBh2E-1t=UXWUQ@HIDDEN>
References: <CAKgn5nzLLZxDOTQ7Doy5yMxiZ9WA9Tf0J0QjfBh2E-1t=UXWUQ@HIDDEN>
Date: Thu, 18 Jun 2026 22:57:57 -0700
Message-ID: <87h5mz6pi2.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 1.3 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: Sick Pigs writes: > 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 phy [...]
Content analysis details: (1.3 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (collin.funk1[at]gmail.com)
1.0 FORGED_GMAIL_RCVD 'From' gmail.com does not match 'Received'
headers
0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends
in digit (collin.funk1[at]gmail.com)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/,
no trust [2607:f8b0:4864:20:0:0:0:132f listed in]
[list.dnswl.org]
X-Debbugs-Envelope-To: 81269
Cc: 81269 <at> debbugs.gnu.org, Paul Eggert <eggert@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.3 (/)
Sick Pigs <sickpigs789@HIDDEN> writes:
> 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=3Dprogre=
ss
>
> 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=3Dn=
one
>
> 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 cons=
umer 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)
It sounds like fsync took ~5.5s on your system. Can you check that? You
can check with the following command:
$ strace -tt -T dd if=3Dimage.iso of=3D/dev/sda bs=3D4M conv=3Dfsync \
status=3Dprogress
Note that the output can get quite long. If you share it on list you can
just remove all of the lines aside from the fysnc and a few lines before
and after. E.g., using:
$ strace -tt -T dd if=3Dimage.iso of=3D/dev/sda bs=3D4M conv=3Dfsync \
status=3Dprogress 2>&1 > /dev/null | tail -n 20
I believe the behavior is expected, at least after the following commit:
$ git log c4f9554ee923c27529cdb76b6f75051183f59c1a -n 1
commit c4f9554ee923c27529cdb76b6f75051183f59c1a
Author: Paul Eggert <eggert@HIDDEN>
AuthorDate: Thu Jan 27 18:34:09 2022 -0800
Commit: Paul Eggert <eggert@HIDDEN>
CommitDate: Thu Jan 27 18:35:02 2022 -0800
=20=20=20=20
dd: output final progress before syncing
=20=20=20=20=20=20=20=20
Problem reported by Sworddragon (Bug#51482).
* src/dd.c (reported_w_bytes): New var.
(print_xfer_stats): Set it.
(dd_copy): Print a final progress report if useful before
synchronizing output data.
Before that change, if there was a final progress indication that had to
be printed it would occur after fdatasync/fsync. Since those system
calls can, and often do, take a long time you would see a tiny
throughput [1] [2].
I guess the current behavior is confusing as well, but I feel like it is
slightly less confusing then the behavior before that change.
Collin
[1] https://bugs.gnu.org/51345
[2] https://bugs.gnu.org/51482
bug-coreutils@HIDDEN:bug#81269; Package coreutils.
Full text available.
Received: (at submit) by debbugs.gnu.org; 19 Jun 2026 03:54:36 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jun 18 23:54:36 2026
Received: from localhost ([127.0.0.1]:48143 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1waQJO-0004Zc-Ph
for submit <at> debbugs.gnu.org; Thu, 18 Jun 2026 23:54:35 -0400
Received: from lists1p.gnu.org ([2001:470:142::17]:37556)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <sickpigs789@HIDDEN>)
id 1waIgH-0006sf-G7
for submit <at> debbugs.gnu.org; Thu, 18 Jun 2026 15:45:42 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10])
by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <sickpigs789@HIDDEN>)
id 1waIgB-0002Ht-01
for bug-coreutils@HIDDEN; Thu, 18 Jun 2026 15:45:35 -0400
Received: from mail-ej1-x62c.google.com ([2a00:1450:4864:20::62c])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.90_1) (envelope-from <sickpigs789@HIDDEN>)
id 1waIg8-0004aH-8u
for bug-coreutils@HIDDEN; Thu, 18 Jun 2026 15:45:34 -0400
Received: by mail-ej1-x62c.google.com with SMTP id
a640c23a62f3a-bec3ffb95dbso185430466b.0
for <bug-coreutils@HIDDEN>; Thu, 18 Jun 2026 12:45:30 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1781811929; cv=none;
d=google.com; s=arc-20240605;
b=MFRDukO2zs270l+i7E4DsyJGiEzN3W9+LmYMDxdWLXsDy4xX/M96lXmHo7q1S563qv
9l3D2l8O79hAYXpVogN1UgGZcJEtC5lLA9pfL/DHaR5VxlfWi/r/M4OSMK/Zr+dIgO6c
7v/IoC5bqWcNYpfDVHVguEkXYtI9mdfiCXLpxEDgCBfLM3D4csIImL8NWxrXH9f9tHfN
p/ziFswAP7TwqDQhV8bjoFgDHCurFsNqfBYpLUr7qEsNBZX2VSC90QXWB/5xG8V0ecL4
7phwktiYioJ5QNA2kjVahQyqqaXOonmxJwuJdVUsfd6hNZvWnjSRkh6HlLvD0EhNKzXo
L6QA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;
s=arc-20240605;
h=to:subject:message-id:date:from:mime-version:dkim-signature;
bh=kMCmVVxwVAosl+yh5Vne5oS6HOT+IiL/IpG3XgRjHC4=;
fh=ScPEsXXZxjUO/SyfaKBND7w77mVWHCttHT1i+nAxu0Q=;
b=jPz+JsbeLeyARI0iJwbozqPcOQM/PnRJZCV0Q+0awujwd6SL2OiZyuB7FUtu/YeTVk
tWZq6vxTghyFmR6klb0N2Jk+QbIWpZKeT1GCnQBrspQVGH//R5PhhtC3WKDh0tS7FzZA
RlA54/JsoYE58e9hSKr3FIHp2lY0nHUl/LsISxcv9WYRnKq+4Zi5hCgSbp0kYBKt8jBp
E1PBdiAaTK73PcasQs+dOWI+DBWVphJko0vfDcZDfVV8G3kPOOK7NyhlWoEOcc9g3et/
WRRAgUy2zTRODwhGS6mHrJZgHKWkgZVcjhSoGhotNIF6tqG/ZveCjEHmFX7GN6Z60OwF
qYXA==; darn=gnu.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20251104; t=1781811929; x=1782416729; darn=gnu.org;
h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
:date:message-id:reply-to;
bh=kMCmVVxwVAosl+yh5Vne5oS6HOT+IiL/IpG3XgRjHC4=;
b=pQee4vFp/xxwvjjDQ+5tn7ML5vOiac7b8jGMKjhfMS17r8/xyUPXoR41RBECXpNxM1
yDjv8+z8wG5f5HalsaEpWyY0ylM5cJHuUUVn23bUeyfmuCtlBbT/3fgeRaey+wgJ96Sw
f+3Qzi7FRfpFfV7R4lR0/FlFfItbtDAdYCbtbwM//nZXqEUnGPLxStGSbsbn26oh4meT
4EScakDW7ieqf4ipehhZH0cK5pJtoWGW6cNprA900NmX+ZwEb6FIY0It3/REIwJ2TOhT
vqhCiL7Z2meNuQW5rBcPC2a7xDh4wHnQ2j5jC5euHE1GTeKi4BNx7CTP69w2cjRgfUZI
pXXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20251104; t=1781811929; x=1782416729;
h=to:subject:message-id:date:from:mime-version:x-gm-gg
:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
bh=kMCmVVxwVAosl+yh5Vne5oS6HOT+IiL/IpG3XgRjHC4=;
b=EuKc+vDk8+iI9KrvNcRoQd65Q4HKP6DAhOIAbcalCQjH90SCmCbTNiGze029vNkUxg
bJROx3/YVtFrDzvXYtOMvpU6h5hmJ7fFYJiG/eh3ei/i6lFjXpa5TcYEpelns68z2f6E
/jzUpsnpB34pgBfpBfoxx9otEBThkphz+q/O0eDxEZmgtkpxZ10lDvfYk/IZHTieetRN
TdaewvTeBg60IySSSfhgniu53l17/D7f0zD57Cv5CJk4vEVdvJcDGZLD0Jo+PGsXTAOR
H0nfu9zPe5em4xt26B8RIo4To1diw/Kq0plSglc9VzXrNN+/qpJBXvSVJzAMqXrX+IP0
/MIg==
X-Gm-Message-State: AOJu0Yy5FkYqOhQlHfJcMUDA0+d6wl2f973mwGCT+Mw+XUh7RDLrGWvR
Xxcq8u6njXo/kyzlplZSkFlFNkdc8yUJtWNXGERkWifeuJV4WtFh12oiYczVudNn28KLjkZXIXu
YZZb1VMim19Y0PksmH6IzbsgtKc8XciCr7DGHfdw=
X-Gm-Gg: AfdE7cnxGlOgXvzhGLfVJ8e9yR5fGBiTr7TQcxXEYGENSRwLHZgY71mOM+6Te8cB78H
lMwenZIh+GoW80PEmC9QY949DB9olHIOkwlbDBrllnmuuLNuCMoI3hI8SRy717n2V5/oA6P/klc
oGnU9hy76ODfPO4+i5b4Fq+L580KTmkqfnmBWLrc31zShRfp2zp4M6RSB0CdwAPUie4cAMYIKEC
UTY9X39VEPnmw/xrgBhlYhkpzseDuf11mA1Acf9yjkdlK9eQZUaLZU5jYogVbObqE7okmU0aBvu
CqlNDAfVuoBY7QpGS2qXqODcEo/xFg==
X-Received: by 2002:a17:907:807:b0:c08:4e8b:ac97 with SMTP id
a640c23a62f3a-c097b38a244mr34157666b.16.1781811928504; Thu, 18 Jun 2026
12:45:28 -0700 (PDT)
MIME-Version: 1.0
From: Sick Pigs <sickpigs789@HIDDEN>
Date: Thu, 18 Jun 2026 20:45:17 +0100
X-Gm-Features: AVVi8CcJX8ixK-4Xgu0MA0XY4cto7GXmshoDAKMK9R6d3YO952AwGKaBLKCmg3E
Message-ID: <CAKgn5nzLLZxDOTQ7Doy5yMxiZ9WA9Tf0J0QjfBh2E-1t=UXWUQ@HIDDEN>
Subject: dd (coreutils 9.7): incorrect elapsed time reporting causes
impossible throughput (7.9 GB/s)
To: bug-coreutils@HIDDEN
Content-Type: multipart/alternative; boundary="0000000000000e1e4506548c6bdd"
Received-SPF: pass client-ip=2a00:1450:4864:20::62c;
envelope-from=sickpigs789@HIDDEN; helo=mail-ej1-x62c.google.com
X-Spam_score_int: -17
X-Spam_score: -1.8
X-Spam_bar: -
X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001,
RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 2.2 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: 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 [...]
Content analysis details: (2.2 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail)
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (sickpigs789[at]gmail.com)
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
1.0 FORGED_GMAIL_RCVD 'From' gmail.com does not match 'Received'
headers
0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends
in digit (sickpigs789[at]gmail.com)
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/,
no trust [2001:470:142:0:0:0:0:17 listed in] [list.dnswl.org]
0.0 HTML_MESSAGE BODY: HTML included in message
X-Debbugs-Envelope-To: submit
X-Mailman-Approved-At: Thu, 18 Jun 2026 23:54:33 -0400
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.2 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: 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 [...]
Content analysis details: (1.2 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail)
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (sickpigs789[at]gmail.com)
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
1.0 FORGED_GMAIL_RCVD 'From' gmail.com does not match 'Received'
headers
0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends
in digit (sickpigs789[at]gmail.com)
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/,
no trust
[2001:470:142:0:0:0:0:17 listed in]
[list.dnswl.org]
0.0 HTML_MESSAGE BODY: HTML included in message
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
--0000000000000e1e4506548c6bdd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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.
--0000000000000e1e4506548c6bdd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Package: coreutils<br>Version: 9.7<br>Severity: normal<br>=
<br>Dear coreutils maintainers,<br><br>I believe I have found a reproducibl=
e bug in GNU dd where the reported elapsed time<br>(and therefore throughpu=
t) is incorrect, even though the actual data is written correctly. This lea=
ds to physically impossible speed reporting (e.g. 7.9 GB/s to a SATA SSD).<=
br><br>System Information:<br><br>OS:<br>Linux nobara-pc 7.0.9-200.nobara.f=
c43.x86_64 #1 SMP PREEMPT_DYNAMIC<br><br>dd version:<br>dd (coreutils) 9.7<=
br><br>Device:<br>/dev/sda (SATA SSD, EDILOCA ES580E 240GB)<br><br>Commands=
Run:<br><br>1) Write ISO to disk:<br>sudo dd if=3Dimage.iso of=3D/dev/sda =
bs=3D4M conv=3Dfsync status=3Dprogress<br><br>627+1 records in<br>627+1 rec=
ords out<br>2630580224 bytes copied, 0.33473 s, 7.9 GB/s<br><br>2) Independ=
ent timing verification:<br>time sudo dd if=3Dimage.iso of=3D/dev/sda bs=3D=
4M conv=3Dfsync status=3Dnone<br><br>real 0m5.782s<br>user 0m0.004s<b=
r>sys 0m0.012s<br><br>3) Verification of correctness:<br>cmp image.iso =
/dev/sda<br>(no output, exit status 0)<br><br>4) Additional test:<br>Using =
oflag=3Ddirect produces the same incorrect timing behavior.<br><br>Kernel c=
onfirms write and partition table update:<br>GPT warnings appear for /dev/s=
da after write, confirming device was modified.<br><br>Expected Behaviour:<=
br>The elapsed time reported by dd should match wall-clock time, or at leas=
t be consistent with external timing tools like `time`. Throughput should b=
e consistent with actual device performance (~400=E2=80=93550 MB/s for cons=
umer SATA SSD).<br><br>Actual Behaviour:<br>dd reports elapsed time of ~0.3=
3s, implying ~7.9 GB/s throughput, which is physically impossible for the h=
ardware. However, external timing (`time`) shows the operation actually too=
k ~5.8s, and the written data is correct.<br><br>Additiuonal Notes:<br><br>=
The issue appears to be purely in dd's internal timing/statistics repor=
ting, not in the actual write operation itself, which completes correctly.<=
br>I can reproduce this consistently with:<br>- status=3Dprogress<br>- conv=
=3Dfsync<br>- coreutils 9.7<br>- Linux kernel 7.0.9 (Nobara)<br><br>Thank y=
ou for your time.</div>
--0000000000000e1e4506548c6bdd--
Sick Pigs <sickpigs789@HIDDEN>:bug-coreutils@HIDDEN.
Full text available.bug-coreutils@HIDDEN:bug#81269; Package coreutils.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.