GNU bug report logs - #51345
dd with conv=fsync sometimes returns when its writes are still cached

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: coreutils; Reported by: Sworddragon <sworddragon2@HIDDEN>; dated Sat, 23 Oct 2021 09:20:02 UTC; Maintainer for coreutils is bug-coreutils@HIDDEN.

Message received at 51345 <at> debbugs.gnu.org:


Received: (at 51345) by debbugs.gnu.org; 29 Oct 2021 19:58:19 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Oct 29 15:58:19 2021
Received: from localhost ([127.0.0.1]:56032 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mgY15-0001FX-B0
	for submit <at> debbugs.gnu.org; Fri, 29 Oct 2021 15:58:19 -0400
Received: from zimbra.cs.ucla.edu ([131.179.128.68]:48786)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eggert@HIDDEN>) id 1mgY13-0001FH-Ec
 for 51345 <at> debbugs.gnu.org; Fri, 29 Oct 2021 15:58:17 -0400
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id 0F82B160071;
 Fri, 29 Oct 2021 12:58:12 -0700 (PDT)
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032)
 with ESMTP id Rp1c0_coCUEA; Fri, 29 Oct 2021 12:58:11 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id 64E4A1600B8;
 Fri, 29 Oct 2021 12:58:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu
Received: from zimbra.cs.ucla.edu ([127.0.0.1])
 by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id 9VZmF7q6HCIq; Fri, 29 Oct 2021 12:58:11 -0700 (PDT)
Received: from [131.179.64.200] (Penguin.CS.UCLA.EDU [131.179.64.200])
 by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 42C0D160071;
 Fri, 29 Oct 2021 12:58:11 -0700 (PDT)
Message-ID: <d5dca97a-be80-25a1-59f6-80c92aa4b2bd@HIDDEN>
Date: Fri, 29 Oct 2021 12:58:10 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.2.0
Subject: Re: bug#51345:
Content-Language: en-US
To: =?UTF-8?Q?P=c3=a1draig_Brady?= <P@HIDDEN>,
 Sworddragon <sworddragon2@HIDDEN>, 51345 <at> debbugs.gnu.org
References: <CAPg=dnx+XQeyUfk90EchxU6_5_sFXU3AK72cLHNg8ZpvLZ-PSw@HIDDEN>
 <CAPg=dnwQL22jwqz_825Yz3L_DTh0xJTVi8hR4AofZFkcex8PyA@HIDDEN>
 <c9df6556-d3c6-58a7-1f0b-83c5c50a7e5a@HIDDEN>
From: Paul Eggert <eggert@HIDDEN>
Organization: UCLA Computer Science Department
In-Reply-To: <c9df6556-d3c6-58a7-1f0b-83c5c50a7e5a@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -2.4 (--)
X-Debbugs-Envelope-To: 51345
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.4 (---)

On 10/29/21 05:38, P=C3=A1draig Brady wrote:
> I'm leaning towards improving this by always
> doing an fsync on exit if we get a read or write error
> and have successfully written any data, so that
> previously written data is sync'd as requested.

Sounds like a good idea to me too.




Information forwarded to bug-coreutils@HIDDEN:
bug#51345; Package coreutils. Full text available.

Message received at 51345 <at> debbugs.gnu.org:


Received: (at 51345) by debbugs.gnu.org; 29 Oct 2021 16:37:44 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Oct 29 12:37:44 2021
Received: from localhost ([127.0.0.1]:55729 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mgUsx-0000zH-QL
	for submit <at> debbugs.gnu.org; Fri, 29 Oct 2021 12:37:43 -0400
Received: from mail-wr1-f48.google.com ([209.85.221.48]:45004)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <pixelbeat@HIDDEN>) id 1mgUsw-0000z3-Go
 for 51345 <at> debbugs.gnu.org; Fri, 29 Oct 2021 12:37:43 -0400
Received: by mail-wr1-f48.google.com with SMTP id d13so17034830wrf.11
 for <51345 <at> debbugs.gnu.org>; Fri, 29 Oct 2021 09:37:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=sender:subject:to:references:from:message-id:date:user-agent
 :mime-version:in-reply-to:content-language:content-transfer-encoding;
 bh=8ooXbC2kYNUtDTjqQlDJq4iqgKOACKnCqkFF4DKAnRE=;
 b=fQKVxrtHkl5v1KTwljZ2pzg3tnTd2dy5ftvOj+sBwGD5vv300vsIO12LAgqkfveVsG
 OaHjcumMCCQ1HFzVhbyVCtBFKM6StRVbvUy1UnxxgdESFW8PZPrTauDfdFgIOcwvDXaG
 1Qhc1zVNPqhxh2zu/R9a2+aKduiknj505IJH5A1HKDa5gxnU143MH3iJmwAib4tEki3i
 xLng21hvwkcXO0uNVB/qcbzplTu4kEmwbRCdxdyeUr/t4VtpX7wbg09EzPjkBwEFNuX0
 JdQscN+YSJK8T2s05Jbg8mVq6JzMGtu8gj0k7YVFI2GUV2yyqJVrYMnFTqG6C6GJSG1r
 pn7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:sender:subject:to:references:from:message-id
 :date:user-agent:mime-version:in-reply-to:content-language
 :content-transfer-encoding;
 bh=8ooXbC2kYNUtDTjqQlDJq4iqgKOACKnCqkFF4DKAnRE=;
 b=286fz8zjnY0zlhu9kCa1Q8ireFMID0GyNuc3xN9+FF6JSV6+w+njKS/59+MgAhljBj
 OckrlSjvbGpYa+O1HvCxVgGXOLtvhUQGcSjxazGCxDuFuK4UQmyo4ZWTEnq1zeKABaR1
 C/uelhfhiMZm9QQPgzo62yg9CW/9XasqILXgyQ7e3kwc9B4Dnd9MiksZsPZIEsrbCNlQ
 h7PbmNPHI6Q2xRzXhjeS2DF+I1Qn7ITylKi6P7HbyrnZ5Oqydhpdf96wrIoF8TOqMeUk
 4Rr2IPmwUhKgL3r3G32JbZfeyts4wGxCdM4vZfZnCjl3I6jxEFobcwu863T7p6JqFBbB
 8PSg==
X-Gm-Message-State: AOAM531iLv9RYkISbyd8ODe1aAiJOOpSby4/4oxRUqUaqIKN695+fDOk
 zfvvAtNNZx8q9iTxLX2YThZG8rvUaeiSdAo7
X-Google-Smtp-Source: ABdhPJzSOo64PPGj0mxgkLeWcvIB76iphxRhcF0OTZUstL93Yr8Mh/45ha3HL3aKMQpnLNU1uwSnBA==
X-Received: by 2002:a5d:588a:: with SMTP id n10mr16361728wrf.285.1635525456219; 
 Fri, 29 Oct 2021 09:37:36 -0700 (PDT)
Received: from localhost.localdomain
 (86-40-129-104-dynamic.agg2.lod.rsl-rtd.eircom.net. [86.40.129.104])
 by smtp.googlemail.com with UTF8SMTPSA id
 u16sm8909971wmc.21.2021.10.29.09.37.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 29 Oct 2021 09:37:35 -0700 (PDT)
Subject: Re: bug#51345:
To: Sworddragon <sworddragon2@HIDDEN>, 51345 <at> debbugs.gnu.org
References: <CAPg=dnx+XQeyUfk90EchxU6_5_sFXU3AK72cLHNg8ZpvLZ-PSw@HIDDEN>
 <CAPg=dnwQL22jwqz_825Yz3L_DTh0xJTVi8hR4AofZFkcex8PyA@HIDDEN>
From: =?UTF-8?Q?P=c3=a1draig_Brady?= <P@HIDDEN>
Message-ID: <f7a15bb9-491d-006d-9f35-511ef59df9f4@HIDDEN>
Date: Fri, 29 Oct 2021 13:06:31 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:84.0) Gecko/20100101
 Thunderbird/84.0
MIME-Version: 1.0
In-Reply-To: <CAPg=dnwQL22jwqz_825Yz3L_DTh0xJTVi8hR4AofZFkcex8PyA@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Spam-Score: 1.5 (+)
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:  On 28/10/2021 22:59, Sworddragon wrote: > Despite I'm not
 using Linux as main system anymore and wanted to avoid > getting into too
 much work I found some time to do some tests as this issue > bugs me [...]
 Content analysis details:   (1.5 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 (pixelbeat[at]gmail.com)
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 1.1 DATE_IN_PAST_03_06     Date: is 3 to 6 hours before Received: date
 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level
 mail domains are different
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at https://www.dnswl.org/,
 no trust [209.85.221.48 listed in list.dnswl.org]
 -0.0 RCVD_IN_MSPIKE_H2      RBL: Average reputation (+2)
 [209.85.221.48 listed in wl.mailspike.net]
 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and
 EnvelopeFrom freemail headers are different
 -0.1 NICE_REPLY_A           Looks like a legit reply (A)
X-Debbugs-Envelope-To: 51345
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.5 (/)

On 28/10/2021 22:59, Sworddragon wrote:
> Despite I'm not using Linux as main system anymore and wanted to avoid
> getting into too much work I found some time to do some tests as this issue
> bugs me just too much.
> 
>> You could try running the following immediately after,
>> to see if it also returns quickly:
>>
>>    blockdev --flushbufs /dev/sdb
> 
> Yes, this command also blocks for a bit over 1 minute when this issue
> occurs.

Right, so that suggests conv=fsync on dd was ineffective.

> Here is the output (I had to freely translate the strings since
> this Knoppix instance is only in german so they might be slightly
> inaccurate; Also I had to type all text since it was executed on a
> different system but carefully checked to not introduce any typos):
> 
> root@Microknoppix:~# dd if=/dev/random of=/dev/sdb bs=1M conv=fsync
> status=progress
> 1039138816 Bytes(1,0 GB, 991 MiB) copied, 56 s, 18,5 MB/s
> dd: Error on writing '/dev/sdb': The device has not enough free space
> 999+0 records in
> 998+0 records out

Ah right. What's probably happening is that dd is not doing the fsync
because it's exiting early because of the ENOSPC from write(2).

To avoid needing the buffer drain (with fsync), you can use




Information forwarded to bug-coreutils@HIDDEN:
bug#51345; Package coreutils. Full text available.

Message received at 51345 <at> debbugs.gnu.org:


Received: (at 51345) by debbugs.gnu.org; 29 Oct 2021 13:32:42 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Oct 29 09:32:42 2021
Received: from localhost ([127.0.0.1]:54227 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mgRzu-0001CU-AV
	for submit <at> debbugs.gnu.org; Fri, 29 Oct 2021 09:32:42 -0400
Received: from mail-yb1-f179.google.com ([209.85.219.179]:43969)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <sworddragon2@HIDDEN>) id 1mgRzs-0001CC-Fr
 for 51345 <at> debbugs.gnu.org; Fri, 29 Oct 2021 09:32:41 -0400
Received: by mail-yb1-f179.google.com with SMTP id a129so11130383yba.10
 for <51345 <at> debbugs.gnu.org>; Fri, 29 Oct 2021 06:32:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:from:date:message-id:subject:to;
 bh=5Vf0G1Pw4soyyWus3l3KD4rK0xxZotrgX/0H57228NI=;
 b=Izli+8PaqZgTmb/e/+tgyQuJCVKt/eer/YZKhPhLR53CmzSaJW9DsYAS4ANemJ3G02
 xOtA8jBbW84RnkZhMchKBTAUWGVTPKHj86wqcvpnZQfha/0OdLlQ+Yt6onWpYasUvs4U
 qAJNbO8MKtObfeMnn26b8aL0/T089zZvOra7j6hxkaM9OVqVOVvnzaFBu6rMEuh7ShbT
 r6GrXdDmOzlhEgKS0sLWWzMViu+40orpgAErf45uKTm/3o3YWTHJSUleyjuk0GeeyStU
 Pon2XfYiiFvVHpeW21t94GoMryMuuwenQg1AGtKh4iOZhvM89h6MiOWpf5suhSjjfEOi
 M1jQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=5Vf0G1Pw4soyyWus3l3KD4rK0xxZotrgX/0H57228NI=;
 b=Sjcz3WFxBxKypqKLHdObJNQ6p/CQTB//6Wu8piKQvO5I6C1fPs81updsQ6e45R39lP
 hu96YMb4N8rHw8NK/kLx7Ei3EUcIdPb2dubkfboV9XuNvjsZDvRnWfcc7XtHgBIhnQ9z
 xueKQhot6CZl9+r6vC2DEsmDINOXU4+WUY+yJLbrJ29oqYWzJTK9WkpDmZ8Uj/B6D396
 jRtATjiRnqKg0j6Loqw6Nh6Iy7uMYjmdRRbQhP8bo1wA8nrIBpon1lwZ3cxRrys+aUV/
 6LbZANaF4fVaLKS+OWcfBLlyR6TnTmc/MYxsgSHjSEQsT4DuSMPc4lbkT7cXbIWOADUR
 UXAw==
X-Gm-Message-State: AOAM533Sof1HSnzElYQRGkKWJZnvg9Qo8o1fUtAnE83ZoOHR4XdkJoZM
 Qj/1SmymXmSIgnTb7zT75eqC4tl0WNTJozEbqzB8zaPzBJA=
X-Google-Smtp-Source: ABdhPJz1uYDY+YzcpgIZYcrMWzV6Qy0m0/XItT8OvYd8rF3Vf8v2+t7Se7uqynhBl2zfVcEBG7Dd4KUnOF0dIhGdLgk=
X-Received: by 2002:a25:11ca:: with SMTP id 193mr11605778ybr.453.1635514354686; 
 Fri, 29 Oct 2021 06:32:34 -0700 (PDT)
MIME-Version: 1.0
From: Sworddragon <sworddragon2@HIDDEN>
Date: Fri, 29 Oct 2021 13:32:25 +0000
Message-ID: <CAPg=dnyUsjHi3zJaRaWmwmBfG8J9zoa02ev=Jj9gLko5Q3AeTg@HIDDEN>
Subject: 
To: 51345 <at> debbugs.gnu.org
Content-Type: multipart/alternative; boundary="00000000000022dfdc05cf7ddc02"
X-Spam-Score: 2.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:  I got an email that somebody replied to this report but it
 looks like they did send it to the wrong mail address (maybe they will be
 merged in order) but I will still reply to it: > Suggestion as a possible
 workaround: Have a look at random(4) and random(7), > and ask yourself whether
 your use of /dev/random, rather than /dev/urandom, > is really necessary
 for your application. [...] 
 Content analysis details:   (2.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 (sworddragon2[at]gmail.com)
 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends
 in digit (sworddragon2[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 [209.85.219.179 listed in list.dnswl.org]
 -0.0 RCVD_IN_MSPIKE_H2      RBL: Average reputation (+2)
 [209.85.219.179 listed in wl.mailspike.net]
 0.0 HTML_MESSAGE           BODY: HTML included in message
 2.0 BLANK_SUBJECT          Subject is present but empty
X-Debbugs-Envelope-To: 51345
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.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:  I got an email that somebody replied to this report but it
    looks like they did send it to the wrong mail address (maybe they will be
    merged in order) but I will still reply to it: > Suggestion as a possible
    workaround: Have a look at random(4) and random(7), > and ask yourself whether
    your use of /dev/random, rather than /dev/urandom, > is really necessary
   for your application. [...] 
 
 Content analysis details:   (1.3 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 RCVD_IN_MSPIKE_H2      RBL: Average reputation (+2)
                             [209.85.219.179 listed in wl.mailspike.net]
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at https://www.dnswl.org/,
                              no trust
                             [209.85.219.179 listed in list.dnswl.org]
 -0.0 SPF_PASS               SPF: sender matches SPF record
  0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
                             provider (sworddragon2[at]gmail.com)
  0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends
                             in digit (sworddragon2[at]gmail.com)
  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
  0.0 HTML_MESSAGE           BODY: HTML included in message
  2.0 BLANK_SUBJECT          Subject is present but empty
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager

--00000000000022dfdc05cf7ddc02
Content-Type: text/plain; charset="UTF-8"

I got an email that somebody replied to this report but it looks like they
did send it to the wrong mail address (maybe they will be merged in order)
but I will still reply to it:

> Suggestion as a possible workaround: Have a look at random(4) and
random(7),
> and ask yourself whether your use of /dev/random, rather than
/dev/urandom,
> is really necessary for your application. If not, you might try
/dev/urandom
> instead and report what you observe.
>
> As documented in those man pages, there are good reasons to avoid using
> /dev/random, not the least of which is that it blocks frequently (every
time
> the entropy pool is exhausted), whereas /dev/urandom does not. That alone
may
> explain the execution time inconsistencies you're reporting.

I'm aware of the differences of both and I don't see how the use of
/dev/random here could explain any of the issues:

- The drastically increased writing times are caused after dd claimed about
no free empty space (assuming this means dd has finished doing its explicit
writing task, e.g. writing to the transparent underlying cache) and dd's
times until this point were fine implying that either significant blocking
has never occured or dd correcly handles blocking input files by
asynchronously continuing to write to the output file to avoid unneccessary
delays.
- That dd returns while the buffers are not flushed can't also be explained
by the use of /dev/random unless there would be some very crazy out of mind
bug somewhere.

But I still did some tests with /dev/urandom and conv=fsync and I did see
all 3 cases too (Normal writing times that are slightly longer (133.247s);
Drastically increased writing times (235.906s) and early returning from dd
(56.4327s) while an immediated executed sync still blocked for over a
minute).

Also for the slightly delayed writing times (~133s with conv=fsync compared
to ~129s with oflag=direct) I noticed that with conv=fsync the LED of the
USB Thumb Drive starts to blink a few seconds after dd started showing
status progress so I assume Knoppix's kernel/settings cause the cache to be
flushed slightly delayed which seems more or less normal and would explain
this specific case of being ~4s slower.


And while I was writing this the next message got in:


> Ah right. What's happening is dd is not doing the fsync()
> as it's exiting early due to write(2) getting ENOSPC.

But that would make not much sense for 2 reasons:

1. The error message that the space went empty is the expected behavior
here and there is no rational dd should exit then instead of still calling
fsync().
2. In the most attempts after dd has thrown the error message about no free
empty space it still blocked for at least over a minute and an immediated
excuted sync always returned.

So it looks dd sometimes does call fsync() on ENOSPC and sometimes it
doesn't. And why a successfull call to fsync() then is sometimes ~2.5
slower is also a mystery.


> So this is a gotcha that should at least be documented.
> Though I'm leaning towards improving this by always
> doing an fsync on exit if we get a read or write error
> and have successfully written any data, so that
> previously written data is sync'd as requested.

Yes, ensuring fsync() being called seems to be the better option here. But
this still leaves the question from above why dd seemingly does this
sometimes already on ENOSPC? Maybe it is a race between ENOSPC and fsync()
in dd causing this bug? Eventually the sometimes occuring very delayed
writes (e.g. ~235s instead of ~133s) play a role here?

--00000000000022dfdc05cf7ddc02
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I got an email that somebody replied to this report b=
ut it looks like they did send it to the wrong mail address (maybe they wil=
l be merged in order) but I will still reply to it:</div><div><br></div><di=
v>&gt; Suggestion as a possible workaround: Have a look at random(4) and ra=
ndom(7),<br>&gt; and ask yourself whether your use of /dev/random, rather t=
han /dev/urandom,<br>&gt; is really necessary for your application. If not,=
 you might try /dev/urandom<br>&gt; instead and report what you observe.<br=
>&gt;<br>&gt; As documented in those man pages, there are good reasons to a=
void using<br>&gt; /dev/random, not the least of which is that it blocks fr=
equently (every time<br>&gt; the entropy pool is exhausted), whereas /dev/u=
random does not. That alone may<br>&gt; explain the execution time inconsis=
tencies you&#39;re reporting.</div><div><br></div><div>I&#39;m aware of the=
 differences of both and I don&#39;t see how the use of /dev/random here co=
uld explain any of the issues:</div><div><br></div><div>- The drastically i=
ncreased writing times are caused after dd claimed about no free empty spac=
e (assuming this means dd has finished doing its explicit writing task, e.g=
. writing to the transparent underlying cache) and dd&#39;s times until thi=
s point were fine implying that either significant blocking has never occur=
ed or dd correcly handles blocking input files by asynchronously continuing=
 to write to the output file to avoid unneccessary delays.</div><div>- That=
 dd returns while the buffers are not flushed can&#39;t also be explained b=
y the use of /dev/random unless there would be some very crazy out of mind =
bug somewhere.</div><div><br></div><div>But I still did some tests with /de=
v/urandom and conv=3Dfsync and I did see all 3 cases too (Normal writing ti=
mes that are slightly longer (133.247s); Drastically increased writing time=
s (235.906s) and early returning from dd (56.4327s) while an immediated exe=
cuted sync still blocked for over a minute).</div><div><br></div><div>Also =
for the slightly delayed writing times (~133s with conv=3Dfsync compared to=
 ~129s with oflag=3Ddirect) I noticed that with conv=3Dfsync the LED of the=
 USB Thumb Drive starts to blink a few seconds after dd started showing sta=
tus progress so I assume Knoppix&#39;s kernel/settings cause the cache to b=
e flushed slightly delayed which seems more or less normal and would explai=
n this specific case of being ~4s slower.</div><div><br></div><div><br></di=
v><div>And while I was writing this the next message got in:<br></div><div>=
<br></div><div><br></div><div>&gt; Ah right. What&#39;s happening is dd is =
not doing the fsync()<br>&gt; as it&#39;s exiting early due to write(2) get=
ting ENOSPC.</div><div><br></div><div>But that would make not much sense fo=
r 2 reasons:</div><div><br></div><div>1. The error message that the space w=
ent empty is the expected behavior here and there is no rational dd should =
exit then instead of still calling fsync().</div><div>2. In the most attemp=
ts after dd has thrown the error message about no free empty space it still=
 blocked for at least over a minute and an immediated excuted sync always r=
eturned.</div><div><br></div><div>So it looks dd sometimes does call fsync(=
) on ENOSPC and sometimes it doesn&#39;t. And why a successfull call to fsy=
nc() then is sometimes ~2.5 slower is also a mystery.<br></div><div><br></d=
iv><div><br></div><div>&gt; So this is a gotcha that should at least be doc=
umented.<br>&gt; Though I&#39;m leaning towards improving this by always<br=
>&gt; doing an fsync on exit if we get a read or write error<br>&gt; and ha=
ve successfully written any data, so that<br>&gt; previously written data i=
s sync&#39;d as requested.</div><div><br></div><div>Yes, ensuring fsync() b=
eing called seems to be the better option here. But this still leaves the q=
uestion from above why dd seemingly does this sometimes already on ENOSPC? =
Maybe it is a race between ENOSPC and fsync() in dd causing this bug? Event=
ually the sometimes occuring very delayed writes (e.g. ~235s instead of ~13=
3s) play a role here?<br></div></div>

--00000000000022dfdc05cf7ddc02--




Information forwarded to bug-coreutils@HIDDEN:
bug#51345; Package coreutils. Full text available.

Message received at 51345 <at> debbugs.gnu.org:


Received: (at 51345) by debbugs.gnu.org; 29 Oct 2021 12:38:51 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Oct 29 08:38:51 2021
Received: from localhost ([127.0.0.1]:54100 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mgR9k-0005jf-7W
	for submit <at> debbugs.gnu.org; Fri, 29 Oct 2021 08:38:51 -0400
Received: from mail-wm1-f50.google.com ([209.85.128.50]:45741)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <pixelbeat@HIDDEN>) id 1mgR9g-0005jN-J2
 for 51345 <at> debbugs.gnu.org; Fri, 29 Oct 2021 08:38:46 -0400
Received: by mail-wm1-f50.google.com with SMTP id
 g191-20020a1c9dc8000000b0032fbf912885so3449092wme.4
 for <51345 <at> debbugs.gnu.org>; Fri, 29 Oct 2021 05:38:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=sender:subject:to:references:from:message-id:date:user-agent
 :mime-version:in-reply-to:content-language:content-transfer-encoding;
 bh=bv5vu4D/M8Py3R/2IEqt4yF4b73Kcs2JCqkHGYdP8go=;
 b=mrppGhXJnf4gL5VQEvDq6XjBQqglAFoldUtDbGfWmZ78SUfyJfBjopzX9PDKLQ80Fc
 Sj0u0jvJCdLMWSpkPSzFcdDVk5HVt5oRRZhn8deWPE0luxdPXU1AxsVIuiYUsTBgODwe
 ehmIiDMHnhmrDTupBc5OCOSvjGvYJRghdTO29ClqlWz9p291KTTH95g1F8ZT3VFuUvw1
 MSc2cHquh5b+4vcKeo5FRyRHdeh25gRRpJRtsdZQJeSb2GpbopQjhPqTggpOcUN3brWa
 JaCC6rkw9mfc+srBbPbvaI51h/V4kqgwFsEo1Q9cROq2+j+ydZxpYiev6Ntxtw1WnChS
 ds8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:sender:subject:to:references:from:message-id
 :date:user-agent:mime-version:in-reply-to:content-language
 :content-transfer-encoding;
 bh=bv5vu4D/M8Py3R/2IEqt4yF4b73Kcs2JCqkHGYdP8go=;
 b=3DQFGB2SEReW56yKkQPSeZPHH2qjblvTt5Kp05VviupfiAUmxU6gXDgqj6eJK7ptn2
 ZcM6+q0yHT5MhP95WiYoPYN+THbkqGzEV/PxyCx8dneWIvf+bj39wSFN4FBcsUuO7ysY
 4rAmvfmnd9VG15YRjKDXRWgEqYZMiYd/t7quZkXmRC39JLCVVprd1iQfEYbUmAAORUK8
 uwNPIRVBZ2/ZeSDYUWgEcfIfhh/nSyPIReLkwm39wb70fqzfEA97ig3R7DS5krQXzXoj
 P/LibxeMtms5RsRlYLUDJW0TP+x02rsNhKDmia9P1jOG2E+DVOSFFQ2KfwwBR51deOAl
 WqJw==
X-Gm-Message-State: AOAM533kp6BaZdDP5h3Tq0j8hYBqqUDxo/8gIBnVl42q1Y1wVY/1PFa0
 sJzxpYQAt4PeM/8MBKaKEzJNWS2aj/gW4TO/
X-Google-Smtp-Source: ABdhPJxkmFw8Ozzc6X4q+cuWX+0QOEuTa8/uugj8oECDatprfQ9H+HdXaTlX3rpXiTNA88u9tVvoKA==
X-Received: by 2002:a05:600c:190a:: with SMTP id
 j10mr11223114wmq.184.1635511118247; 
 Fri, 29 Oct 2021 05:38:38 -0700 (PDT)
Received: from localhost.localdomain
 (86-40-129-104-dynamic.agg2.lod.rsl-rtd.eircom.net. [86.40.129.104])
 by smtp.googlemail.com with UTF8SMTPSA id
 p21sm4950173wmc.11.2021.10.29.05.38.36
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 29 Oct 2021 05:38:37 -0700 (PDT)
Subject: Re: bug#51345:
To: Sworddragon <sworddragon2@HIDDEN>, 51345 <at> debbugs.gnu.org
References: <CAPg=dnx+XQeyUfk90EchxU6_5_sFXU3AK72cLHNg8ZpvLZ-PSw@HIDDEN>
 <CAPg=dnwQL22jwqz_825Yz3L_DTh0xJTVi8hR4AofZFkcex8PyA@HIDDEN>
From: =?UTF-8?Q?P=c3=a1draig_Brady?= <P@HIDDEN>
Message-ID: <c9df6556-d3c6-58a7-1f0b-83c5c50a7e5a@HIDDEN>
Date: Fri, 29 Oct 2021 13:38:36 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:84.0) Gecko/20100101
 Thunderbird/84.0
MIME-Version: 1.0
In-Reply-To: <CAPg=dnwQL22jwqz_825Yz3L_DTh0xJTVi8hR4AofZFkcex8PyA@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.4 (/)
X-Debbugs-Envelope-To: 51345
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.6 (/)

On 28/10/2021 22:59, Sworddragon wrote:
> Despite I'm not using Linux as main system anymore and wanted to avoid
> getting into too much work I found some time to do some tests as this issue
> bugs me just too much.
> 
>> You could try running the following immediately after,
>> to see if it also returns quickly:
>>
>>    blockdev --flushbufs /dev/sdb
> 
> Yes, this command also blocks for a bit over 1 minute when this issue
> occurs.

Right that suggests the conv=fsync to dd was ineffective

> Here is the output (I had to freely translate the strings since
> this Knoppix instance is only in german so they might be slightly
> inaccurate; Also I had to type all text since it was executed on a
> different system but carefully checked to not introduce any typos):
> 
> root@Microknoppix:~# dd if=/dev/random of=/dev/sdb bs=1M conv=fsync
> status=progress
> 1039138816 Bytes(1,0 GB, 991 MiB) copied, 56 s, 18,5 MB/s
> dd: Error on writing '/dev/sdb': The device has not enough free space
> 999+0 records in
> 998+0 records out

Ah right. What's happening is dd is not doing the fsync()
as it's exiting early due to write(2) getting ENOSPC.

As you've seen you can avoid the need for fsync()
to flush buffers with oflag=direct.
A reason that might be faster also is that depending on your free mem,
you would avoid churning the kernel caches.

Another way to at least ensure the conv=fsync was effective,
would be to not write too much.  I.e. you could determine
the exact size of the disk (with `blockdev --getsize64 /dev/sdb` for e.g.)
and then use an appropriate bs= and count=. That's awkward though
and difficult to do with good performance due to larger block sizes
not generally aligning with the device size.

So this is a gotcha that should at least be documented.
Though I'm leaning towards improving this by always
doing an fsync on exit if we get a read or write error
and have successfully written any data, so that
previously written data is sync'd as requested.

cheers,
Pádraig




Information forwarded to bug-coreutils@HIDDEN:
bug#51345; Package coreutils. Full text available.

Message received at 51345 <at> debbugs.gnu.org:


Received: (at 51345) by debbugs.gnu.org; 28 Oct 2021 23:56:05 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Oct 28 19:56:05 2021
Received: from localhost ([127.0.0.1]:53521 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mgFFZ-0006aL-62
	for submit <at> debbugs.gnu.org; Thu, 28 Oct 2021 19:56:05 -0400
Received: from mail-yb1-f170.google.com ([209.85.219.170]:45715)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <sworddragon2@HIDDEN>) id 1mgDQg-0001WX-62
 for 51345 <at> debbugs.gnu.org; Thu, 28 Oct 2021 17:59:22 -0400
Received: by mail-yb1-f170.google.com with SMTP id y80so18883109ybe.12
 for <51345 <at> debbugs.gnu.org>; Thu, 28 Oct 2021 14:59:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:from:date:message-id:subject:to;
 bh=KOlu1c1su8v/MoZDdqbAXhH+SY2W64s5RDcuckIB3As=;
 b=J01fm1Ue45+o8oFK1kDGQNYwVjhTVVirJV6FbkkGGBOPQCV+CCmM08BH6gF71dBsiS
 knC5y3B0L+CKXGX8WFgdY0ywjCrnJf2L4IqpqEQrMn2jDsXFVAAZQ24jVb9TW4gcOili
 rN+5Gh8TPsz1EJUun1ZOJpfWAjS0wcJEdMUjsB1aX4YkNZPf4Rr4AlFGAuePt5E4pSgP
 kYphbM3mrPqrNBn+Mv+xwDN8Ua7jE0BUD3gK07JT8d7YzgZYiFE8xrZ68fPAKWBWkzMy
 A+I02Si8copDwB0jDom/ycGSUPnLRnS2ziXsyqTeRcvBjSjq+nJL1AVF8QmcokUvfHsV
 KhnA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=KOlu1c1su8v/MoZDdqbAXhH+SY2W64s5RDcuckIB3As=;
 b=xabd4oPAxgJZHe0iPuv0DE9LK+JeF6nJOGnRM7zIPnh8Vei6+g6FI3UnxK+iFjjy4w
 yvxzV7ZTXtFVTk073PvjOdbttg+80GD1sqA0YyTryJeWGHef+QNQan/Vp6jBON9OyTTn
 QhJA894ilIyjdcU7x+UtwGZjuiiEMiojv0yByftAqpOFt0VeGB09HH8S+BRTQcChrZD+
 /r3+QlUgQkvVoKzJ7w9qWPi8X2zwncf3gsXh6xewGSPrOFtLzejSTR7ENQhdtdUZUL+A
 X+7S8aeBHLahFLxO4zK1gVcGoe/oT5Do9l8imFgfyDS2RTQsEqbfcYCu9ubeMgtb1vJG
 nSLQ==
X-Gm-Message-State: AOAM531JF0LbZihZJH0IIW4w+3lUr7Gc98iawhs1M4AKAJSwEvZjlPDt
 Jbw/bo/C9TF6Acv7Ti7Gb+3b6Q/jyBF4/q5ViUWVPMg4urEXKw==
X-Google-Smtp-Source: ABdhPJwRq9DUn86nGD8LM0bi6BVTcjtxkR2tVFaZHL7wKb5g4if+0scIo+zN7a9updal5CrmYVVwMA+irgTejeFYMLk=
X-Received: by 2002:a25:abae:: with SMTP id v43mr4207428ybi.204.1635458356253; 
 Thu, 28 Oct 2021 14:59:16 -0700 (PDT)
MIME-Version: 1.0
From: Sworddragon <sworddragon2@HIDDEN>
Date: Thu, 28 Oct 2021 21:59:06 +0000
Message-ID: <CAPg=dnwQL22jwqz_825Yz3L_DTh0xJTVi8hR4AofZFkcex8PyA@HIDDEN>
Subject: 
To: 51345 <at> debbugs.gnu.org
Content-Type: multipart/alternative; boundary="0000000000005e974505cf70d200"
X-Spam-Score: 2.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: Despite I'm not using Linux as main system anymore and wanted
 to avoid getting into too much work I found some time to do some tests as
 this issue bugs me just too much. > You could try running the following
 immediately
 after, > to see if it also returns quickly: > > blockdev --flushbufs /dev/sdb
 Content analysis details:   (2.3 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at https://www.dnswl.org/,
 no trust [209.85.219.170 listed in list.dnswl.org]
 -0.0 SPF_PASS               SPF: sender matches SPF record
 -0.0 RCVD_IN_MSPIKE_H2      RBL: Average reputation (+2)
 [209.85.219.170 listed in wl.mailspike.net]
 0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
 provider (sworddragon2[at]gmail.com)
 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends
 in digit (sworddragon2[at]gmail.com)
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 0.0 HTML_MESSAGE           BODY: HTML included in message
 2.0 BLANK_SUBJECT          Subject is present but empty
X-Debbugs-Envelope-To: 51345
X-Mailman-Approved-At: Thu, 28 Oct 2021 19:55:59 -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.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:  Despite I'm not using Linux as main system anymore and wanted
    to avoid getting into too much work I found some time to do some tests as
    this issue bugs me just too much. > You could try running the following immediately
    after, > to see if it also returns quickly: > > blockdev --flushbufs /dev/sdb
    
 
 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 (sworddragon2[at]gmail.com)
  0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends
                             in digit (sworddragon2[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
                             [209.85.219.170 listed in list.dnswl.org]
 -0.0 RCVD_IN_MSPIKE_H2      RBL: Average reputation (+2)
                             [209.85.219.170 listed in wl.mailspike.net]
  0.0 HTML_MESSAGE           BODY: HTML included in message
  2.0 BLANK_SUBJECT          Subject is present but empty
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager

--0000000000005e974505cf70d200
Content-Type: text/plain; charset="UTF-8"

Despite I'm not using Linux as main system anymore and wanted to avoid
getting into too much work I found some time to do some tests as this issue
bugs me just too much.

> You could try running the following immediately after,
> to see if it also returns quickly:
>
>   blockdev --flushbufs /dev/sdb

Yes, this command also blocks for a bit over 1 minute when this issue
occurs. Here is the output (I had to freely translate the strings since
this Knoppix instance is only in german so they might be slightly
inaccurate; Also I had to type all text since it was executed on a
different system but carefully checked to not introduce any typos):

root@Microknoppix:~# dd if=/dev/random of=/dev/sdb bs=1M conv=fsync
status=progress
1039138816 Bytes(1,0 GB, 991 MiB) copied, 56 s, 18,5 MB/s
dd: Error on writing '/dev/sdb': The device has not enough free space
999+0 records in
998+0 records out
1047526912 Bytes (1,0 GB, 999 MiB) copied, 57,0283 s, 18,4 MB/s
root@Microknoppix:~# time blockdev --flushbufs /dev/sdb

real    1m9,747s
user    0m0,001s
sys     0m0,005s


(A bit offtopic, but maybe another minor bug: The first line of the copied
bytes differ slightly with every attempt (like 991 MiB, 994 MiB, 997 MiB,
etc.) but the last line seems to be always the same up to the last byte. I
had the impression the output from status=progress does not do a final
update once dd throws the writing error because the free space went out, is
my assumption correct? If so, it would probably make sense and be helpful
for others on debugging attempts if dd would do a final update. But back to
the original topic)


> Also with rates status.
>
>     dd if=/dev/random of=/dev/sdb bs=1M oflag=direct status=progress

With conv=fsync the bug usually occurs every 3-4 attempts (but the sample
size is small) so I decided to do 20 attempts with oflag=direct. The issue
did not appear once and every attempt was roughly 129 seconds (+/- 0.5
seconds) and an executed sync afterwards always returned immediately. Does
direct I/O signal the related storage device to not use its bultin-cache?
If not this implies that the USB Thumb Drive's firmware is very likely not
faulty and does not contribute to this issue.

But I noticed some other thing (I also noticed it in the past but it got
now my attention after all the stable oflag=direct writes): With conv=fsync
the writing time is sometimes around double as high as it should be. On
doing now 3 attempts with it dd showed me final times of 244,382s, 239,127s
and 135,389s, while the status progress always stopped after 56s. So
waiting for the buffers to be flushed after dd claimed about no free empty
storage space the times differ very significantly at best roughly as fast
as oflag=direct and at worst ~2.5 times slower than they should be.


To sum this up we have 2 issues:

1. The status progress from status=progress does not make a final update
(which would be useful) - but that is offtopic and probably easy to fix so
I guess there is no more for me to do here.
2. fsync returns often either early when the buffers are not fully flushed
yet or it drastically increases the writing time compared to normal
attempts (even the normal attempts are apparently quite a bit slower than
direct I/O while probably the opposite should be the case) which is very
likely either a bug in dd or something in the Linux Kernel's fsync()
imlementation is very broken.

--0000000000005e974505cf70d200
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Despite I&#39;m not using Linux as main system anymor=
e and wanted to avoid getting into too much work I found some time to do so=
me tests as this issue bugs me just too much.<br></div><div><br></div><div>=
&gt; You could try running the following immediately after,<br>&gt; to see =
if it also returns quickly:<br>&gt;<br>&gt; =C2=A0 blockdev --flushbufs /de=
v/sdb</div><div><br></div><div>Yes, this command also blocks for a bit over=
 1 minute when this issue occurs. Here is the output (I had to freely trans=
late the strings since this Knoppix instance is only in german so they migh=
t be slightly inaccurate; Also I had to type all text since it was executed=
 on a different system but carefully checked to not introduce any typos):</=
div><div><br></div><div>root@Microknoppix:~# dd if=3D/dev/random of=3D/dev/=
sdb bs=3D1M conv=3Dfsync status=3Dprogress</div><div>1039138816 Bytes(1,0 G=
B, 991 MiB) copied, 56 s, 18,5 MB/s</div><div>dd: Error on writing &#39;/de=
v/sdb&#39;: The device has not enough free space</div><div>999+0 records in=
</div><div>998+0 records out</div><div>1047526912 Bytes (1,0 GB, 999 MiB) c=
opied, 57,0283 s, 18,4 MB/s</div><div>
root@Microknoppix:~# time blockdev --flushbufs /dev/sdb</div><div><br></div=
><div>real=C2=A0=C2=A0=C2=A0 1m9,747s<br></div><div>user=C2=A0=C2=A0=C2=A0 =
0m0,001s<br></div><div>sys=C2=A0=C2=A0=C2=A0=C2=A0 0m0,005s</div><div><br><=
/div><div><br></div><div>(A bit offtopic, but maybe another minor bug: The =
first line of the copied bytes differ slightly with every attempt (like 991=
 MiB, 994 MiB, 997 MiB, etc.) but the last line seems to be always the same=
 up to the last byte. I had the impression the output from status=3Dprogres=
s does not do a final update once dd throws the writing error because the f=
ree space went out, is my assumption correct? If so, it would probably make=
 sense and be helpful for others on debugging attempts if dd would do a fin=
al update. But back to the original topic)</div><div><br></div><div><br></d=
iv><div>&gt; Also with rates status.<br>&gt;<br>&gt; =C2=A0 =C2=A0 dd if=3D=
/dev/random of=3D/dev/sdb bs=3D1M oflag=3Ddirect status=3Dprogress</div><di=
v><br></div><div>With conv=3Dfsync the bug usually occurs every 3-4 attempt=
s (but the sample size is small) so I decided to do 20 attempts with oflag=
=3Ddirect. The issue did not appear once and every attempt was roughly 129 =
seconds (+/- 0.5 seconds) and an executed sync afterwards always returned i=
mmediately. Does direct I/O signal the related storage device to not use it=
s bultin-cache? If not this implies that the USB Thumb Drive&#39;s firmware=
 is very likely not faulty and does not contribute to this issue.</div><div=
><br></div><div>But I noticed some other thing (I also noticed it in the pa=
st but it got now my attention after all the stable oflag=3Ddirect writes):=
 With conv=3Dfsync the writing time is sometimes around double as high as i=
t should be. On doing now 3 attempts with it dd showed me final times of 24=
4,382s, 239,127s and 135,389s, while the status progress always stopped aft=
er 56s. So waiting for the buffers to be flushed after dd claimed about no =
free empty storage space the times differ very significantly at best roughl=
y as fast as oflag=3Ddirect and at worst ~2.5 times slower than they should=
 be.</div><div><br></div><div><br></div><div>To sum this up we have 2 issue=
s:</div><div><br></div><div>1. The status progress from status=3Dprogress d=
oes not make a final update (which would be useful) - but that is offtopic =
and probably easy to fix so I guess there is no more for me to do here.</di=
v><div>2. fsync returns often either early when the buffers are not fully f=
lushed yet or it drastically increases the writing time compared to normal =
attempts (even the normal attempts are apparently quite a bit slower than d=
irect I/O while probably the opposite should be the case) which is very lik=
ely either a bug in dd or something in the Linux Kernel&#39;s fsync() imlem=
entation is very broken.<br></div></div>

--0000000000005e974505cf70d200--




Information forwarded to bug-coreutils@HIDDEN:
bug#51345; Package coreutils. Full text available.

Message received at 51345 <at> debbugs.gnu.org:


Received: (at 51345) by debbugs.gnu.org; 26 Oct 2021 00:19:32 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 25 20:19:32 2021
Received: from localhost ([127.0.0.1]:44680 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mfABf-0007mq-RL
	for submit <at> debbugs.gnu.org; Mon, 25 Oct 2021 20:19:32 -0400
Received: from havoc.proulx.com ([96.88.95.61]:52064)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <bob@HIDDEN>) id 1mfABe-0007mZ-JA
 for 51345 <at> debbugs.gnu.org; Mon, 25 Oct 2021 20:19:30 -0400
Received: from joseki.proulx.com (localhost [127.0.0.1])
 by havoc.proulx.com (Postfix) with ESMTP id 2DCD8382;
 Mon, 25 Oct 2021 18:19:25 -0600 (MDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proulx.com;
 s=dkim2048; t=1635207565;
 bh=xa7jwOKNJ5lrdcOq8p+D+0nlTf00spn4b03j6rFHWlI=;
 h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
 b=SohQNqyWNSqg0qtocdv5CPuUS2OVCNVxFV+QkSYhJZOiZqw2j6U3nXVx/8o0KmQB8
 X/WKSTJC+spS5h0MnLFTH+42Dlno8qjcsdfpVv882kwGih4FyGIgA8xDJgQnOnCOvc
 XYoIt3wnknvNzmMchHTCyRe16W7s0MuB4d/K+FFQsI3sAUyVUin3xbJoclH+Lf7rED
 wAVbkJkL9MTtLPqi4jkQntVn8bSm2Ck57XvwA0WT4iaRkpBLlrNf/Q9qgg73LfFPrj
 krKWKhWjwf3jptsy30mSHPWfjcfwVUSIeBGpEopnt/uow36AKsgctE2007+ekMazXD
 x1wRlaKHLJzyA==
Received: from hysteria.proulx.com (hysteria.proulx.com [192.168.230.119])
 by joseki.proulx.com (Postfix) with ESMTP id 038757A033;
 Mon, 25 Oct 2021 18:19:25 -0600 (MDT)
Received: by hysteria.proulx.com (Postfix, from userid 1000)
 id EDEEC2DCA1; Mon, 25 Oct 2021 18:19:24 -0600 (MDT)
Date: Mon, 25 Oct 2021 18:19:24 -0600
From: Bob Proulx <bob@HIDDEN>
To: Sworddragon <sworddragon2@HIDDEN>
Subject: Re: bug#51345: dd with conv=fsync sometimes returns when its writes
 are still cached
Message-ID: <20211025181450324942121@HIDDEN>
References: <CAPg=dnx+XQeyUfk90EchxU6_5_sFXU3AK72cLHNg8ZpvLZ-PSw@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAPg=dnx+XQeyUfk90EchxU6_5_sFXU3AK72cLHNg8ZpvLZ-PSw@HIDDEN>
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 51345
Cc: 51345 <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: -1.0 (-)

Sworddragon wrote:
> On Knoppix 9.1 with the Linux Kernel 5.10.10-64 x86_64 and GNU Coreutils
> 8.32 I wanted to overwrite my USB Thumb Drive a few times with random data
> via "dd if=/dev/random of=/dev/sdb bs=1M conv=fsync". While it usually
> takes ~2+ minutes to perform this action dd returned once after less than
> 60 seconds which made me a bit curious.

I suggest another try using oflag=direct instead of conv=fsync.

    dd if=/dev/random of=/dev/sdb bs=1M oflag=direct

Also with rates status.

    dd if=/dev/random of=/dev/sdb bs=1M oflag=direct status=progress

Here is the documentation for it.

  ‘oflag=FLAG[,FLAG]...’

     ‘direct’
          Use direct I/O for data, avoiding the buffer cache.  Note that
          the kernel may impose restrictions on read or write buffer
          sizes.  For example, with an ext4 destination file system and
          a Linux-based kernel, using ‘oflag=direct’ will cause writes
          to fail with ‘EINVAL’ if the output buffer size is not a
          multiple of 512.

Bob





Information forwarded to bug-coreutils@HIDDEN:
bug#51345; Package coreutils. Full text available.

Message received at 51345 <at> debbugs.gnu.org:


Received: (at 51345) by debbugs.gnu.org; 24 Oct 2021 08:31:34 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Oct 24 04:31:34 2021
Received: from localhost ([127.0.0.1]:37880 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1meYui-0004pM-5F
	for submit <at> debbugs.gnu.org; Sun, 24 Oct 2021 04:31:34 -0400
Received: from mail-yb1-f176.google.com ([209.85.219.176]:36543)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <sworddragon2@HIDDEN>) id 1meY3D-0001In-5V
 for 51345 <at> debbugs.gnu.org; Sun, 24 Oct 2021 03:36:15 -0400
Received: by mail-yb1-f176.google.com with SMTP id e138so6559219ybc.3
 for <51345 <at> debbugs.gnu.org>; Sun, 24 Oct 2021 00:36:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:from:date:message-id:subject:to;
 bh=95dCZNLFz4H1hbShBTUg/mWdX36HM+VIGh18lHkqi7c=;
 b=TigycGRnPw3Bg/OAE7xtO2ohUfO6QJvQeZMs/BNrweFDAWHzlYtt/Ax05H+WWSWEjw
 6xi9PAgeMTaYXmT1nPDEYlGA2FQTGUeYy3A+EdcCBjnPftFg5iM+A8DhxL3ESscp87UY
 x5JL5G28h0qOzmWDKz/GNJtUz+9LhE6Rsfzj+/Olx1Mcwr3ee3pCdaKaej/uCzMcMtDE
 pQlMl9oTb4XivP4FRxQCYC2WmZjXkoA2xmUkdq+oV2tsrwgQV5PtHYOZ47wk671GDAK3
 hNIBAC5clsqjT8G5a9DFqXyS2kGfXfRcojiZIrQiRIikECcBkSZAvDQ6E+lbhDLLoWPN
 7Y3Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=95dCZNLFz4H1hbShBTUg/mWdX36HM+VIGh18lHkqi7c=;
 b=HPQMFlJfq7MVtIS2beUwfb4vSTwj9k7ppAfjl6nW5BnbEy5MKSMreHv1CZ+CiDWcS8
 qXtt3cAS68J+0CfMIoKM6kg6KDTeK+vb9aVB54kKR7vTmePbkfqtIz6M0a1OtpmWAaR6
 FRv8uAuEjq2IXWPgd4TX0ZK0gfng5VOlxJ/ea+jnC8gQRVDTeOmmVvKVoNG0fBybecQ2
 FgKTkqBg/OZaRRcHNFM+7JVN3twtw/13VhjdtLCil40KrfWsUkO+1d9IfvtKObZfXJT1
 7hWnhflkzJd667TAy3u4VNkplNVai5MSyxIFzWhRuFbFsQYjwFwykIPMEO/Ce0f0JK8q
 abdg==
X-Gm-Message-State: AOAM531Nde9MbZo/3YZZb4YFs+O2HFrQwQHm+gUMVJNOxVOSxnQ/+er/
 VnZMrbsVHRDqtpWx/Xpg3NVzCnjYQZ7R1O9QP7vEIytgDHE=
X-Google-Smtp-Source: ABdhPJx9Au0SmgVyFK5lDMK4HCwG7GefaMGSw+qGcnxPZwC39ZYuxCX9h2nu00Rqt1gaxBDsiwug/NMn00r4UkT8FDA=
X-Received: by 2002:a25:1f83:: with SMTP id f125mr6569711ybf.533.1635060969583; 
 Sun, 24 Oct 2021 00:36:09 -0700 (PDT)
MIME-Version: 1.0
From: Sworddragon <sworddragon2@HIDDEN>
Date: Sun, 24 Oct 2021 07:35:59 +0000
Message-ID: <CAPg=dnx7nyWU=eyCXfR+xkY56zB3Pj8WYT_cSngTX0b6Q32g4A@HIDDEN>
Subject: 
To: 51345 <at> debbugs.gnu.org
Content-Type: multipart/alternative; boundary="00000000000047389b05cf144cda"
X-Spam-Score: 2.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:  > You could try running the following immediately after, >
 to see if it also returns quickly: > > blockdev --flushbufs /dev/sdb The
 issue does not reproduce always and the related USB Thumb Drive has already
 been prepared for and does store important data so that is not an easy task.
 The USB Thumb Drive is also a pretty old de [...] 
 Content analysis details:   (2.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 (sworddragon2[at]gmail.com)
 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends
 in digit (sworddragon2[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 [209.85.219.176 listed in list.dnswl.org]
 -0.0 RCVD_IN_MSPIKE_H2      RBL: Average reputation (+2)
 [209.85.219.176 listed in wl.mailspike.net]
 0.0 HTML_MESSAGE           BODY: HTML included in message
 2.0 BLANK_SUBJECT          Subject is present but empty
X-Debbugs-Envelope-To: 51345
X-Mailman-Approved-At: Sun, 24 Oct 2021 04:31:30 -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.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:  > You could try running the following immediately after, >
    to see if it also returns quickly: > > blockdev --flushbufs /dev/sdb The
   issue does not reproduce always and the related USB Thumb Drive has already
    been prepared for and does store important data so that is not an easy task.
    The USB Thumb Drive is also a pretty old de [...] 
 
 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 (sworddragon2[at]gmail.com)
  0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends
                             in digit (sworddragon2[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
                             [209.85.219.176 listed in list.dnswl.org]
 -0.0 RCVD_IN_MSPIKE_H2      RBL: Average reputation (+2)
                             [209.85.219.176 listed in wl.mailspike.net]
  0.0 HTML_MESSAGE           BODY: HTML included in message
  2.0 BLANK_SUBJECT          Subject is present but empty
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager

--00000000000047389b05cf144cda
Content-Type: text/plain; charset="UTF-8"

> You could try running the following immediately after,
> to see if it also returns quickly:
>
>    blockdev --flushbufs /dev/sdb


The issue does not reproduce always and the related USB Thumb Drive has
already been prepared for and does store important data so that is not an
easy task. The USB Thumb Drive is also a pretty old device (roughly 10
years or even older) with only 1 GB of storage space. When dd with
conv=fsync returned after half of its usual writing time I guess it is
unlikely that the controller of the USB Thumb Drive has its own dedicated
512 MiB buffer attached to it.


> Well we're relying on the kernel here to not return from fync()
> until appropriate.

But the question is if there is a minor unobvious bug somewhere is the
controlling logic of dd that might still cause such a bug. But I checked
the manpages for the sync() and fsync() calls and they are actually quite
interesting. fsync() describes as flushing the caches for even data
retrieval after crashes/reboots. But the interesting part here is that it
describes after that it blocks until the devices reports completion. But
what happens if the device reports completion even if the kernel still sees
cached writes in its memory-mapped area (since storage devices are like
their own small computers and could lie or have faulty firmwares)? If
fsync() returns early here it would not be against the documention in the
manpage. sync() is here more simple as it describes itself as writing all
pending modifications for file (meta)data to the underlying filesystems. If
this would result returning after the device reports completion but the
kernel still sees cached writes in its context that would be strictly a
bug. The interesting part here is that the notes section of sync() sets
sync(), syncfs() and fsync() equal in guarantees.

With this information I see 3 possibilities here:

1. This is a bug in the controlling logic of dd that might not be obvious
at all.
2. This is a bug in fsync() or somewhere more below in the Linux Kernel.
3. Returning early is the intended behavior of fsync() and does not
strictly conflict with the manpage.

If the last is the case it might be worth proposing a change to the Linux
Kernel to additionally ensure that all cached writes are being sent out
from the Kernel's context before a return from fsync() is possible. It
would also mean that currently users can't rely on fsync() (e.g. via dd
with conv=fsync) to ensure the data has been flushed - instead they would
need to take additional action like executing a sync in the terminal
afterwards.

--00000000000047389b05cf144cda
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt;=20
You could try running the following immediately after,<br>
&gt; to see if it also returns quickly:<br>
&gt;<br><div>&gt;=C2=A0 =C2=A0 blockdev --flushbufs /dev/sdb<br></div><div>=
<br></div><div><br></div><div>The issue does not reproduce always and the r=
elated USB Thumb Drive has already been prepared for and does store importa=
nt data so that is not an easy task. The USB Thumb Drive is also a pretty o=
ld device (roughly 10 years or even older) with only 1 GB of storage space.=
 When dd with conv=3Dfsync returned after half of its usual writing time I =
guess it is unlikely that the controller of the USB Thumb Drive has its own=
 dedicated 512 MiB buffer attached to it.<br></div><div><br></div><div><br>=
</div><div>&gt;=20
Well we&#39;re relying on the kernel here to not return from fync()<br>&gt;=
 until appropriate.<br></div><div><br></div><div>But the question is if the=
re is a minor unobvious bug somewhere is the controlling logic of dd that m=
ight still cause such a bug. But I checked the manpages for the sync() and =
fsync() calls and they are actually quite interesting. fsync() describes as=
 flushing the caches for even data retrieval after crashes/reboots. But the=
 interesting part here is that it describes after that it blocks until the =
devices reports completion. But what happens if the device reports completi=
on even if the kernel still sees cached writes in its memory-mapped area (s=
ince storage devices are like their own small computers and could lie or ha=
ve faulty firmwares)? If fsync() returns early here it would not be against=
 the documention in the manpage. sync() is here more simple as it describes=
 itself as writing all pending modifications for file (meta)data to the und=
erlying filesystems. If this would result returning after the device report=
s completion but the kernel still sees cached writes in its context that wo=
uld be strictly a bug. The interesting part here is that the notes section =
of sync() sets sync(), syncfs() and fsync() equal in guarantees.</div><div>=
<br></div><div>With this information I see 3 possibilities here:</div><div>=
<br></div><div>1. This is a bug in the controlling logic of dd that might n=
ot be obvious at all.</div><div>2. This is a bug in fsync() or somewhere mo=
re below in the Linux Kernel.</div><div>3. Returning early is the intended =
behavior of fsync() and does not strictly conflict with the manpage.</div><=
div><br></div><div>If the last is the case it might be worth proposing a ch=
ange to the Linux Kernel to additionally ensure that all cached writes are =
being sent out from the Kernel&#39;s context before a return from fsync() i=
s possible. It would also mean that currently users can&#39;t rely on fsync=
() (e.g. via dd with conv=3Dfsync) to ensure the data has been flushed - in=
stead they would need to take additional action like executing a sync in th=
e terminal afterwards.<br></div></div>

--00000000000047389b05cf144cda--




Information forwarded to bug-coreutils@HIDDEN:
bug#51345; Package coreutils. Full text available.

Message received at 51345 <at> debbugs.gnu.org:


Received: (at 51345) by debbugs.gnu.org; 23 Oct 2021 12:55:35 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Oct 23 08:55:35 2021
Received: from localhost ([127.0.0.1]:34643 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1meGYg-0000fB-R7
	for submit <at> debbugs.gnu.org; Sat, 23 Oct 2021 08:55:35 -0400
Received: from mail-wr1-f49.google.com ([209.85.221.49]:39911)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <pixelbeat@HIDDEN>) id 1meGYd-0000ex-2p
 for 51345 <at> debbugs.gnu.org; Sat, 23 Oct 2021 08:55:32 -0400
Received: by mail-wr1-f49.google.com with SMTP id z14so2007010wrg.6
 for <51345 <at> debbugs.gnu.org>; Sat, 23 Oct 2021 05:55:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=sender:subject:to:references:from:message-id:date:user-agent
 :mime-version:in-reply-to:content-language:content-transfer-encoding;
 bh=UeHoMiaaTtqbVaScj1a3DIN9JCsPUXll3zwBJdrZ4kM=;
 b=KhBE473Ue/Iifn6M04JL+0piMLQQbpyXfCoGGV0YU81E6fYM3f8IOggJpOxW+eIBI7
 GrY0iy93y2x6QRZPIcrM3oEqn1Ikn2PxHdrLbmf8Jk8+p8rsN96+ae0OHLf4uAA5Vn/n
 TpwIlMIFlw960ofunLsuq/DHwM4Z0khGINbwOPBJaLMSwU1GtwlnexHQy0f7zy86RZIf
 akMCLRdj0dulbUjbxsOorewjEm88yBCVUP8BIFzj2NiU8XcQKjDE0cSdv34V/+nUdBcb
 ORwP9TTxMnMHUhmDz9e7jMUhNSNzORj/W0JdFU2RCQZFLisrNUlOIBUO6W7l66y3mOKv
 /VjQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:sender:subject:to:references:from:message-id
 :date:user-agent:mime-version:in-reply-to:content-language
 :content-transfer-encoding;
 bh=UeHoMiaaTtqbVaScj1a3DIN9JCsPUXll3zwBJdrZ4kM=;
 b=yhk9XX3BKJCkXC9pTJXI8lsZzXtVQyolY6eZ/QKiCviW0pCYW1Zw9+Ib0goyh01DdP
 D4GZMQu1aaCmr1QbFH12hwax8M32Y/zMpTZxCwmzCTI9pSolfEa1J9/C+f7vTmb896zT
 EWxhdA3XdBRG3Gpp78wfJE2CGr6VGV2QlNwMXM6lyHj0pYy8DQFH1g+3bPWbrmclYDS0
 o99pW9C3G0xnzjcYcRpp4zFfckuoPCordTO7ZDoCngfF7zvjT/NJ/BBa6TmGydr/cmRE
 eHWV/mHSlUCVePzld83eP6YtRg14U1QPtjcni9Eg+R64uLqBlD1roQd+XWb89sh3tich
 u14Q==
X-Gm-Message-State: AOAM531ZICab3+xjBHcK66ARpNRTfY1KKi7cZ7F3jg10b1YH7FxOU3Nc
 taG+MJRN9c4I2D71IlUDZGmriQLb6cayaHWo
X-Google-Smtp-Source: ABdhPJzZ5J0h+5ZK8T/EhcsY0mK63IKp9Dfy7yoHZdVYU/tpRvPl2J63VSl6RJxaGfxeVfx6DEvhEQ==
X-Received: by 2002:a05:6000:249:: with SMTP id
 m9mr7563119wrz.51.1634993724817; 
 Sat, 23 Oct 2021 05:55:24 -0700 (PDT)
Received: from localhost.localdomain
 (86-40-129-104-dynamic.agg2.lod.rsl-rtd.eircom.net. [86.40.129.104])
 by smtp.googlemail.com with UTF8SMTPSA id
 f6sm9997482wmj.28.2021.10.23.05.55.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sat, 23 Oct 2021 05:55:24 -0700 (PDT)
Subject: Re: bug#51345: dd with conv=fsync sometimes returns when its writes
 are still cached
To: Sworddragon <sworddragon2@HIDDEN>, 51345 <at> debbugs.gnu.org
References: <CAPg=dnx+XQeyUfk90EchxU6_5_sFXU3AK72cLHNg8ZpvLZ-PSw@HIDDEN>
From: =?UTF-8?Q?P=c3=a1draig_Brady?= <P@HIDDEN>
Message-ID: <84333eaa-4c8c-31c3-740c-9333091596bb@HIDDEN>
Date: Sat, 23 Oct 2021 13:55:19 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:84.0) Gecko/20100101
 Thunderbird/84.0
MIME-Version: 1.0
In-Reply-To: <CAPg=dnx+XQeyUfk90EchxU6_5_sFXU3AK72cLHNg8ZpvLZ-PSw@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.4 (/)
X-Debbugs-Envelope-To: 51345
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.6 (/)

On 23/10/2021 09:18, Sworddragon wrote:
> On Knoppix 9.1 with the Linux Kernel 5.10.10-64 x86_64 and GNU Coreutils
> 8.32 I wanted to overwrite my USB Thumb Drive a few times with random data
> via "dd if=/dev/random of=/dev/sdb bs=1M conv=fsync". While it usually
> takes ~2+ minutes to perform this action dd returned once after less than
> 60 seconds which made me a bit curious. On a later attempt dd returned with
> this command after ~1 minute again but the LED on my USB Thumb Drive was
> still blinking and an immediated executed sync on the terminal blocked for
> ~1 minute and once it returned the LED on my USB Thumb Drive also stopped
> blinking.
> 
> Knoppix 9.1 was booted as a live system from a DVD and the only another
> persistent storage attached to it was an internal HDD which was already
> overwritten the same way via a past booting session.
> 
> 
> Unfortunately Linux is not my main operating system anymore so I randomly
> encountered this issue on a nearly 1 year old distribution which might be
> slightly outdated. But the issue is pretty severe as it can lead to
> significant data loss so it is worth at least reporting it (and having the
> "bad" behavior to always call sync after dd nonetheless will probably now
> continue to stay for quite a while).
> 

Well we're relying on the kernel here to not return from fync()
until appropriate.  You could try running the following immediately after,
to see if it also returns quickly:

   blockdev --flushbufs /dev/sdb

Note a subsequent `sync /dev/sdb` would probably not be effective,
since that would only consider data written by theh sync process
(which would be nothing).

cheers,
Pádraig




Information forwarded to bug-coreutils@HIDDEN:
bug#51345; Package coreutils. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 23 Oct 2021 09:19:49 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Oct 23 05:19:49 2021
Received: from localhost ([127.0.0.1]:34371 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1meDBs-00011S-Oa
	for submit <at> debbugs.gnu.org; Sat, 23 Oct 2021 05:19:49 -0400
Received: from lists.gnu.org ([209.51.188.17]:57930)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <sworddragon2@HIDDEN>) id 1meCF5-0007xC-Mv
 for submit <at> debbugs.gnu.org; Sat, 23 Oct 2021 04:19:05 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:48108)
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <sworddragon2@HIDDEN>)
 id 1meCF5-0005v7-HE
 for bug-coreutils@HIDDEN; Sat, 23 Oct 2021 04:19:03 -0400
Received: from mail-yb1-xb35.google.com ([2607:f8b0:4864:20::b35]:39697)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.90_1) (envelope-from <sworddragon2@HIDDEN>)
 id 1meCF3-0002Yd-GC
 for bug-coreutils@HIDDEN; Sat, 23 Oct 2021 04:19:03 -0400
Received: by mail-yb1-xb35.google.com with SMTP id 67so12217877yba.6
 for <bug-coreutils@HIDDEN>; Sat, 23 Oct 2021 01:19:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:from:date:message-id:subject:to;
 bh=rTsWIuXkZWQFa9C7ixYH9hYpDrOeGWwfRQ1whob0FSg=;
 b=dkUIIMZI4+tatbsDQ0bnsksAV23yB3VXgm8ZAjSPAWyqiYoUlcJCBaGpzJQB+bm6Jv
 0NVHrKAV+6L1v7sP7rqbQywrkVvOqkd88PM40nC7bPA54VgiwRVoJ1XDovORx8i8JYc2
 YR9pPQvchiBULDeueonb4tRbXx/VbmKsYH1x/mnSbm9n6v7ShIsPN4/dh1P+S4O94fnb
 894K1lx5mlVFeuF/VLgoQrk3kQo5p8F1t3VC4pj+r++zMIRNVNA7oS3nxPiey3nP0uaj
 9MSkizzgV8TBrmG3fPSoRfysv36qFIGy+e0XUxFBcWHxo9XuGChMQCpRNTfABOZ3+wt+
 PLUg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=rTsWIuXkZWQFa9C7ixYH9hYpDrOeGWwfRQ1whob0FSg=;
 b=jYbqQS1tfPxMjL+RqI0IUvM2+R8Y95mDEApUaVhfKrscJjtFLQiDIYaq8Q2h14ZuhV
 DH4rBVCpwba8u2CcQdFpBiis1ttxjhupOXv3ncdwJDvvdqcg6EXQ5LZoq5gDhidsKzrd
 qKeFrwqBvjSz8f7eqaqdHGsyNX9UjTwK+V6mdIyADpnQ23o70PfPQsrzWMws3I+ID5ly
 KgRjmAzDieJwI17IUXzKZ+JIh4pu1fj0MgJ1atZ4Y8F9pFDO1CTmQ80L+1jK9bVG6wuS
 VyuGU8dBTPZe00nBxY0NThFZuI+LNtZkRPNJediZItZahDSAgaYHs/QsyWNQb/Ab25NJ
 R1AA==
X-Gm-Message-State: AOAM532LgCqQZh3E8DmxgOkxpbrbUEbKlhpEOm9J1esVZWZKjIaZAbYa
 mT0ZXVEDMA+grcmvRe37Y53inkvuD8J+4yr0eXtzBqoSKSg=
X-Google-Smtp-Source: ABdhPJw+X/tNmC6ltZbgKiaXT2naegI9iQ2jJBRA+0gUq7rTx7c7mkNAIOJxydcDbXt3a3JZ28eh1h4p67u6fUCaA7o=
X-Received: by 2002:a05:6902:120a:: with SMTP id
 s10mr5078886ybu.453.1634977139670; 
 Sat, 23 Oct 2021 01:18:59 -0700 (PDT)
MIME-Version: 1.0
From: Sworddragon <sworddragon2@HIDDEN>
Date: Sat, 23 Oct 2021 08:18:49 +0000
Message-ID: <CAPg=dnx+XQeyUfk90EchxU6_5_sFXU3AK72cLHNg8ZpvLZ-PSw@HIDDEN>
Subject: dd with conv=fsync sometimes returns when its writes are still cached
To: bug-coreutils@HIDDEN
Content-Type: multipart/alternative; boundary="000000000000a0442905cf00c7af"
Received-SPF: pass client-ip=2607:f8b0:4864:20::b35;
 envelope-from=sworddragon2@HIDDEN; helo=mail-yb1-xb35.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: -1.1 (-)
X-Debbugs-Envelope-To: submit
X-Mailman-Approved-At: Sat, 23 Oct 2021 05:19:47 -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: -2.1 (--)

--000000000000a0442905cf00c7af
Content-Type: text/plain; charset="UTF-8"

On Knoppix 9.1 with the Linux Kernel 5.10.10-64 x86_64 and GNU Coreutils
8.32 I wanted to overwrite my USB Thumb Drive a few times with random data
via "dd if=/dev/random of=/dev/sdb bs=1M conv=fsync". While it usually
takes ~2+ minutes to perform this action dd returned once after less than
60 seconds which made me a bit curious. On a later attempt dd returned with
this command after ~1 minute again but the LED on my USB Thumb Drive was
still blinking and an immediated executed sync on the terminal blocked for
~1 minute and once it returned the LED on my USB Thumb Drive also stopped
blinking.

Knoppix 9.1 was booted as a live system from a DVD and the only another
persistent storage attached to it was an internal HDD which was already
overwritten the same way via a past booting session.


Unfortunately Linux is not my main operating system anymore so I randomly
encountered this issue on a nearly 1 year old distribution which might be
slightly outdated. But the issue is pretty severe as it can lead to
significant data loss so it is worth at least reporting it (and having the
"bad" behavior to always call sync after dd nonetheless will probably now
continue to stay for quite a while).

--000000000000a0442905cf00c7af
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>On Knoppix 9.1 with the Linux Kernel 5.10.10-64 x86_6=
4 and GNU Coreutils 8.32 I wanted to overwrite my USB Thumb Drive a few tim=
es with random data via &quot;dd if=3D/dev/random of=3D/dev/sdb bs=3D1M con=
v=3Dfsync&quot;. While it usually takes ~2+ minutes to perform this action =
dd returned once after less than 60 seconds which made me a bit curious. On=
 a later attempt dd returned with this command after ~1 minute again but th=
e LED on my USB Thumb Drive was still blinking and an immediated executed s=
ync on the terminal blocked for ~1 minute and once it returned the LED on m=
y USB Thumb Drive also stopped blinking.</div><div><br></div><div>Knoppix 9=
.1 was booted as a live system from a DVD and the only another persistent s=
torage attached to it was an internal HDD which was already overwritten the=
 same way via a past booting session.</div><div><br></div><div><br></div><d=
iv>Unfortunately Linux is not my main operating system anymore so I randoml=
y encountered this issue on a nearly 1 year old distribution which might be=
 slightly outdated. But the issue is pretty severe as it can lead to signif=
icant data loss so it is worth at least reporting it (and having the &quot;=
bad&quot; behavior to always call sync after dd nonetheless will probably n=
ow continue to stay for quite a while).<br></div></div>

--000000000000a0442905cf00c7af--




Acknowledgement sent to Sworddragon <sworddragon2@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-coreutils@HIDDEN. Full text available.
Report forwarded to bug-coreutils@HIDDEN:
bug#51345; Package coreutils. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Fri, 29 Oct 2021 20:00:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.