From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 23 05:19:49 2021 Received: (at submit) by debbugs.gnu.org; 23 Oct 2021 09:19:49 +0000 Received: from localhost ([127.0.0.1]:34371 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1meDBs-00011S-Oa for submit@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 ) id 1meCF5-0007xC-Mv for submit@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 ) id 1meCF5-0005v7-HE for bug-coreutils@gnu.org; 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 ) id 1meCF3-0002Yd-GC for bug-coreutils@gnu.org; Sat, 23 Oct 2021 04:19:03 -0400 Received: by mail-yb1-xb35.google.com with SMTP id 67so12217877yba.6 for ; 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 Date: Sat, 23 Oct 2021 08:18:49 +0000 Message-ID: Subject: dd with conv=fsync sometimes returns when its writes are still cached To: bug-coreutils@gnu.org Content-Type: multipart/alternative; boundary="000000000000a0442905cf00c7af" Received-SPF: pass client-ip=2607:f8b0:4864:20::b35; envelope-from=sworddragon2@gmail.com; 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@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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
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 "dd if=3D/dev/random of=3D/dev/sdb bs=3D1M con= v=3Dfsync". 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.

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.


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 "= bad" behavior to always call sync after dd nonetheless will probably n= ow continue to stay for quite a while).
--000000000000a0442905cf00c7af-- From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 23 08:55:35 2021 Received: (at 51345) by debbugs.gnu.org; 23 Oct 2021 12:55:35 +0000 Received: from localhost ([127.0.0.1]:34643 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1meGYg-0000fB-R7 for submit@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 ) id 1meGYd-0000ex-2p for 51345@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@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 , 51345@debbugs.gnu.org References: From: =?UTF-8?Q?P=c3=a1draig_Brady?= Message-ID: <84333eaa-4c8c-31c3-740c-9333091596bb@draigBrady.com> 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: 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@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 From debbugs-submit-bounces@debbugs.gnu.org Sun Oct 24 04:31:34 2021 Received: (at 51345) by debbugs.gnu.org; 24 Oct 2021 08:31:34 +0000 Received: from localhost ([127.0.0.1]:37880 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1meYui-0004pM-5F for submit@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 ) id 1meY3D-0001In-5V for 51345@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@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 Date: Sun, 24 Oct 2021 07:35:59 +0000 Message-ID: Subject: To: 51345@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@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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
>=20 You could try running the following immediately after,
> to see if it also returns quickly:
>
>=C2=A0 =C2=A0 blockdev --flushbufs /dev/sdb
=

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.


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

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.
=
With this information I see 3 possibilities here:
=
1. This is a bug in the controlling logic of dd that might n= ot be obvious at all.
2. This is a bug in fsync() or somewhere mo= re below in the Linux Kernel.
3. Returning early is the intended = behavior of fsync() and does not strictly conflict with the manpage.
<= 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's context before a return from fsync() i= s possible. It would also mean that currently users can'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.
--00000000000047389b05cf144cda-- From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 25 20:19:32 2021 Received: (at 51345) by debbugs.gnu.org; 26 Oct 2021 00:19:32 +0000 Received: from localhost ([127.0.0.1]:44680 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mfABf-0007mq-RL for submit@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 ) id 1mfABe-0007mZ-JA for 51345@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 To: Sworddragon Subject: Re: bug#51345: dd with conv=fsync sometimes returns when its writes are still cached Message-ID: <20211025181450324942121@bob.proulx.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 51345 Cc: 51345@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 28 19:56:05 2021 Received: (at 51345) by debbugs.gnu.org; 28 Oct 2021 23:56:05 +0000 Received: from localhost ([127.0.0.1]:53521 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mgFFZ-0006aL-62 for submit@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 ) id 1mgDQg-0001WX-62 for 51345@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@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 Date: Thu, 28 Oct 2021 21:59:06 +0000 Message-ID: Subject: To: 51345@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@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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
Despite I'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.

= > You could try running the following immediately after,
> to see = if it also returns quickly:
>
> =C2=A0 blockdev --flushbufs /de= v/sdb

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):

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

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

<= /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)


> Also with rates status.
>
> =C2=A0 =C2=A0 dd if=3D= /dev/random of=3D/dev/sdb bs=3D1M oflag=3Ddirect status=3Dprogress

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'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 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.


To sum this up we have 2 issue= s:

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.
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's fsync() imlem= entation is very broken.
--0000000000005e974505cf70d200-- From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 29 08:38:51 2021 Received: (at 51345) by debbugs.gnu.org; 29 Oct 2021 12:38:51 +0000 Received: from localhost ([127.0.0.1]:54100 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mgR9k-0005jf-7W for submit@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 ) id 1mgR9g-0005jN-J2 for 51345@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@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 , 51345@debbugs.gnu.org References: From: =?UTF-8?Q?P=c3=a1draig_Brady?= Message-ID: 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: 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@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 29 09:32:42 2021 Received: (at 51345) by debbugs.gnu.org; 29 Oct 2021 13:32:42 +0000 Received: from localhost ([127.0.0.1]:54227 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mgRzu-0001CU-AV for submit@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 ) id 1mgRzs-0001CC-Fr for 51345@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@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 Date: Fri, 29 Oct 2021 13:32:25 +0000 Message-ID: Subject: To: 51345@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@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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
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:

> Suggestion as a possible workaround: Have a look at random(4) and ra= ndom(7),
> and ask yourself whether your use of /dev/random, rather t= han /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 a= void using
> /dev/random, not the least of which is that it blocks fr= equently (every time
> the entropy pool is exhausted), whereas /dev/u= random does not. That alone may
> explain the execution time inconsis= tencies you're reporting.

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

- 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'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.
- That= dd returns while the buffers are not flushed can't also be explained b= y the use of /dev/random unless there would be some very crazy out of mind = bug somewhere.

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).

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'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.


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) get= ting ENOSPC.

But that would make not much sense fo= r 2 reasons:

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().
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.

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


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

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?
--00000000000022dfdc05cf7ddc02-- From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 29 12:37:44 2021 Received: (at 51345) by debbugs.gnu.org; 29 Oct 2021 16:37:44 +0000 Received: from localhost ([127.0.0.1]:55729 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mgUsx-0000zH-QL for submit@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 ) id 1mgUsw-0000z3-Go for 51345@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@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 , 51345@debbugs.gnu.org References: From: =?UTF-8?Q?P=c3=a1draig_Brady?= Message-ID: 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: 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@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 29 15:58:19 2021 Received: (at 51345) by debbugs.gnu.org; 29 Oct 2021 19:58:19 +0000 Received: from localhost ([127.0.0.1]:56032 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mgY15-0001FX-B0 for submit@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 ) id 1mgY13-0001FH-Ec for 51345@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: 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?= , Sworddragon , 51345@debbugs.gnu.org References: From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: 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@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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. From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 28 03:06:02 2022 Received: (at 51345-done) by debbugs.gnu.org; 28 Jan 2022 08:06:02 +0000 Received: from localhost ([127.0.0.1]:57198 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nDMGg-000125-3T for submit@debbugs.gnu.org; Fri, 28 Jan 2022 03:06:02 -0500 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:38770) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nDMGd-00011Z-JC for 51345-done@debbugs.gnu.org; Fri, 28 Jan 2022 03:06:00 -0500 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 5C1DA160126; Fri, 28 Jan 2022 00:05:53 -0800 (PST) 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 tfBILakKSdc3; Fri, 28 Jan 2022 00:05:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 30996160133; Fri, 28 Jan 2022 00:05:52 -0800 (PST) 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 9fAR_-NCrA74; Fri, 28 Jan 2022 00:05:52 -0800 (PST) Received: from [192.168.1.9] (cpe-172-91-119-151.socal.res.rr.com [172.91.119.151]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 02A82160126; Fri, 28 Jan 2022 00:05:51 -0800 (PST) Content-Type: multipart/mixed; boundary="------------cTC9yfwHvlPlTfuvnpFlpqsK" Message-ID: <15f47a2d-1cb2-fee6-a845-487f16806325@cs.ucla.edu> Date: Fri, 28 Jan 2022 00:05:51 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: bug#51345: dd with conv=fsync sometimes returns when its writes are still cached Content-Language: en-US To: Sworddragon References: From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: X-Spam-Score: -3.4 (---) X-Debbugs-Envelope-To: 51345-done Cc: 51345-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.4 (----) This is a multi-part message in MIME format. --------------cTC9yfwHvlPlTfuvnpFlpqsK Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit I found a bit of time to work on this and installed the attached patch, which should address the issue. Thanks for reporting it. --------------cTC9yfwHvlPlTfuvnpFlpqsK Content-Type: text/x-patch; charset=UTF-8; name="0001-dd-synchronize-output-after-write-errors.patch" Content-Disposition: attachment; filename="0001-dd-synchronize-output-after-write-errors.patch" Content-Transfer-Encoding: base64 RnJvbSAzMzY4Yjg3NDUwNDZhZWFhODlmNDE4ZjU2MGU3MTRiMzc0ZjFhNTYwIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBQYXVsIEVnZ2VydCA8ZWdnZXJ0QGNzLnVjbGEuZWR1 PgpEYXRlOiBGcmksIDI4IEphbiAyMDIyIDAwOjAxOjA3IC0wODAwClN1YmplY3Q6IFtQQVRD SF0gZGQ6IHN5bmNocm9uaXplIG91dHB1dCBhZnRlciB3cml0ZSBlcnJvcnMKClByb2JsZW0g cmVwb3J0ZWQgYnkgU3dvcmRkcmFnb24gKEJ1ZyM1MTM0NSkuCiogc3JjL2RkLmMgKGNsZWFu dXApOiBTeW5jaHJvbml6ZSBvdXRwdXQgdW5sZXNzIGRkIGhhcyBiZWVuIGludGVycnVwdGVk Lgooc3luY2hyb25pemVfb3V0cHV0KTogTmV3IGZ1bmN0aW9uLCBzcGxpdCBvdXQgZnJvbSBk ZF9jb3B5LgpVcGRhdGUgY29udmVyc2lvbnNfbWFzayBzbyBzeW5jaHJvbml6YXRpb24gaXMg ZG9uZSBhdCBtb3N0IG9uY2UuCihtYWluKTogRG8gbm90IGRpZSB3aXRoIHRoZSBvdXRwdXQg ZmlsZSBvcGVuLCBzaW5jZSB3ZSB3YW50IHRvIGJlCmFibGUgdG8gc3luY2hyb25pemUgaXQg YmVmb3JlIGV4aXRpbmcuICBTeW5jaHJvbml6ZSBvdXRwdXQgYmVmb3JlCmV4aXRpbmcuCi0t LQogTkVXUyAgICAgICAgICAgICAgIHwgIDMgKysKIGRvYy9jb3JldXRpbHMudGV4aSB8IDEw ICsrKy0tLQogc3JjL2RkLmMgICAgICAgICAgIHwgNzYgKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrLS0tLS0tLS0tLS0tLQogMyBmaWxlcyBjaGFuZ2VkLCA2NCBpbnNlcnRp b25zKCspLCAyNSBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9ORVdTIGIvTkVXUwppbmRl eCAxNWM5NDI4YmQuLjc1N2FiZWUxNSAxMDA2NDQKLS0tIGEvTkVXUworKysgYi9ORVdTCkBA IC00MSw2ICs0MSw5IEBAIEdOVSBjb3JldXRpbHMgTkVXUyAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIC0qLSBvdXRsaW5lIC0qLQogICBwYWRkaW5nIHRoZW0gd2l0aCB6 ZXJvcyB0byA5IGRpZ2l0cy4gIEl0IHVzZXMgY2xvY2tfZ2V0cmVzIGFuZAogICBjbG9ja19n ZXR0aW1lIHRvIGluZmVyIHRoZSBjbG9jayByZXNvbHV0aW9uLgogCisgIGRkIGNvbnY9ZnN5 bmMgbm93IHN5bmNocm9uaXplcyBvdXRwdXQgZXZlbiBhZnRlciBhIHdyaXRlIGVycm9yLAor ICBhbmQgc2ltaWxhcmx5IGZvciBkZCBjb252PWZkYXRhc3luYy4KKwogICB0aW1lb3V0IC0t Zm9yZWdyb3VuZCAtLWtpbGwtYWZ0ZXI9Li4uIHdpbGwgbm93IGV4aXQgd2l0aCBzdGF0dXMg MTM3CiAgIGlmIHRoZSBraWxsIHNpZ25hbCB3YXMgc2VudCwgd2hpY2ggaXMgY29uc2lzdGVu dCB3aXRoIHRoZSBiZWhhdmlvcgogICB3aGVuIHRoZSAtLWZvcmVncm91bmQgb3B0aW9uIGlz IG5vdCBzcGVjaWZpZWQuICBUaGlzIGFsbG93cyB1c2VycyB0bwpkaWZmIC0tZ2l0IGEvZG9j L2NvcmV1dGlscy50ZXhpIGIvZG9jL2NvcmV1dGlscy50ZXhpCmluZGV4IGMxNzQwNjU1MC4u MDg4ZDE3NjRjIDEwMDY0NAotLS0gYS9kb2MvY29yZXV0aWxzLnRleGkKKysrIGIvZG9jL2Nv cmV1dGlscy50ZXhpCkBAIC05Mzk3LDE0ICs5Mzk3LDE2IEBAIENvbnRpbnVlIGFmdGVyIHJl YWQgZXJyb3JzLgogQGl0ZW0gZmRhdGFzeW5jCiBAb3BpbmRleCBmZGF0YXN5bmMKIEBjaW5k ZXggc3luY2hyb25pemVkIGRhdGEgd3JpdGVzLCBiZWZvcmUgZmluaXNoaW5nCi1TeW5jaHJv bml6ZSBvdXRwdXQgZGF0YSBqdXN0IGJlZm9yZSBmaW5pc2hpbmcuICBUaGlzIGZvcmNlcyBh IHBoeXNpY2FsCi13cml0ZSBvZiBvdXRwdXQgZGF0YS4KK1N5bmNocm9uaXplIG91dHB1dCBk YXRhIGp1c3QgYmVmb3JlIGZpbmlzaGluZywKK2V2ZW4gaWYgdGhlcmUgd2VyZSB3cml0ZSBl cnJvcnMuCitUaGlzIGZvcmNlcyBhIHBoeXNpY2FsIHdyaXRlIG9mIG91dHB1dCBkYXRhLgog CiBAaXRlbSBmc3luYwogQG9waW5kZXggZnN5bmMKIEBjaW5kZXggc3luY2hyb25pemVkIGRh dGEgYW5kIG1ldGFkYXRhIHdyaXRlcywgYmVmb3JlIGZpbmlzaGluZwotU3luY2hyb25pemUg b3V0cHV0IGRhdGEgYW5kIG1ldGFkYXRhIGp1c3QgYmVmb3JlIGZpbmlzaGluZy4gIFRoaXMK LWZvcmNlcyBhIHBoeXNpY2FsIHdyaXRlIG9mIG91dHB1dCBkYXRhIGFuZCBtZXRhZGF0YS4K K1N5bmNocm9uaXplIG91dHB1dCBkYXRhIGFuZCBtZXRhZGF0YSBqdXN0IGJlZm9yZSBmaW5p c2hpbmcsCitldmVuIGlmIHRoZXJlIHdlcmUgd3JpdGUgZXJyb3JzLgorVGhpcyBmb3JjZXMg YSBwaHlzaWNhbCB3cml0ZSBvZiBvdXRwdXQgZGF0YSBhbmQgbWV0YWRhdGEuCiAKIEBlbmQg dGFibGUKIApkaWZmIC0tZ2l0IGEvc3JjL2RkLmMgYi9zcmMvZGQuYwppbmRleCA5NTdhZDEy OWUuLjRkZGM2ZGIxMiAxMDA2NDQKLS0tIGEvc3JjL2RkLmMKKysrIGIvc3JjL2RkLmMKQEAg LTkzOSw2ICs5MzksOCBAQCBpY2xvc2UgKGludCBmZCkKICAgcmV0dXJuIDA7CiB9CiAKK3N0 YXRpYyBpbnQgc3luY2hyb25pemVfb3V0cHV0ICh2b2lkKTsKKwogc3RhdGljIHZvaWQKIGNs ZWFudXAgKHZvaWQpCiB7CkBAIC05NDgsNiArOTUwLDEzIEBAIGNsZWFudXAgKHZvaWQpCiAg IGFsaWduZnJlZSAob2J1Zik7CiAjZW5kaWYKIAorICBpZiAoIWludGVycnVwdF9zaWduYWwp CisgICAgeworICAgICAgaW50IHN5bmNfc3RhdHVzID0gc3luY2hyb25pemVfb3V0cHV0ICgp OworICAgICAgaWYgKHN5bmNfc3RhdHVzKQorICAgICAgICBleGl0IChzeW5jX3N0YXR1cyk7 CisgICAgfQorCiAgIGlmIChpY2xvc2UgKFNURElOX0ZJTEVOTykgIT0gMCkKICAgICBkaWUg KEVYSVRfRkFJTFVSRSwgZXJybm8sIF8oImNsb3NpbmcgaW5wdXQgZmlsZSAlcyIpLCBxdW90 ZWFmIChpbnB1dF9maWxlKSk7CiAKQEAgLTIzNzcsMTcgKzIzODYsMzMgQEAgZGRfY29weSAo dm9pZCkKICAgICAgICYmIDAgPD0gcmVwb3J0ZWRfd19ieXRlcyAmJiByZXBvcnRlZF93X2J5 dGVzIDwgd19ieXRlcykKICAgICBwcmludF94ZmVyX3N0YXRzICgwKTsKIAotICBpZiAoKGNv bnZlcnNpb25zX21hc2sgJiBDX0ZEQVRBU1lOQykgJiYgaWZkYXRhc3luYyAoU1RET1VUX0ZJ TEVOTykgIT0gMCkKKyAgcmV0dXJuIGV4aXRfc3RhdHVzOworfQorCisvKiBTeW5jaHJvbml6 ZSBvdXRwdXQgYWNjb3JkaW5nIHRvIGNvbnZlcnNpb25zX21hc2suCisgICBEbyB0aGlzIGV2 ZW4gaWYgd19ieXRlcyBpcyB6ZXJvLCBhcyBmc3luYyBhbmQgZmRhdGFzeW5jCisgICBmbHVz aCBvdXQgd3JpdGUgcmVxdWVzdHMgZnJvbSBvdGhlciBwcm9jZXNzZXMgdG9vLgorICAgQ2xl YXIgYml0cyBpbiBjb252ZXJzaW9uc19tYXNrIHNvIHRoYXQgc3luY2hyb25pemF0aW9uIGlz IGRvbmUgb25seSBvbmNlLgorICAgUmV0dXJuIHplcm8gaWYgc3VjY2Vzc2Z1bCwgYW4gZXhp dCBzdGF0dXMgb3RoZXJ3aXNlLiAgKi8KKworc3RhdGljIGludAorc3luY2hyb25pemVfb3V0 cHV0ICh2b2lkKQoreworICBpbnQgZXhpdF9zdGF0dXMgPSAwOworICBpbnQgbWFzayA9IGNv bnZlcnNpb25zX21hc2s7CisgIGNvbnZlcnNpb25zX21hc2sgJj0gfiAoQ19GREFUQVNZTkMg fCBDX0ZTWU5DKTsKKworICBpZiAoKG1hc2sgJiBDX0ZEQVRBU1lOQykgJiYgaWZkYXRhc3lu YyAoU1RET1VUX0ZJTEVOTykgIT0gMCkKICAgICB7CiAgICAgICBpZiAoZXJybm8gIT0gRU5P U1lTICYmIGVycm5vICE9IEVJTlZBTCkKICAgICAgICAgewogICAgICAgICAgIGVycm9yICgw LCBlcnJubywgXygiZmRhdGFzeW5jIGZhaWxlZCBmb3IgJXMiKSwgcXVvdGVhZiAob3V0cHV0 X2ZpbGUpKTsKICAgICAgICAgICBleGl0X3N0YXR1cyA9IEVYSVRfRkFJTFVSRTsKICAgICAg ICAgfQotICAgICAgY29udmVyc2lvbnNfbWFzayB8PSBDX0ZTWU5DOworICAgICAgbWFzayB8 PSBDX0ZTWU5DOwogICAgIH0KIAotICBpZiAoKGNvbnZlcnNpb25zX21hc2sgJiBDX0ZTWU5D KSAmJiBpZnN5bmMgKFNURE9VVF9GSUxFTk8pICE9IDApCisgIGlmICgobWFzayAmIENfRlNZ TkMpICYmIGlmc3luYyAoU1RET1VUX0ZJTEVOTykgIT0gMCkKICAgICB7CiAgICAgICBlcnJv ciAoMCwgZXJybm8sIF8oImZzeW5jIGZhaWxlZCBmb3IgJXMiKSwgcXVvdGVhZiAob3V0cHV0 X2ZpbGUpKTsKICAgICAgIHJldHVybiBFWElUX0ZBSUxVUkU7CkBAIC0yNDYwLDYgKzI0ODUs MTYgQEAgbWFpbiAoaW50IGFyZ2MsIGNoYXIgKiphcmd2KQogICAgICAgICAgICB8IChjb252 ZXJzaW9uc19tYXNrICYgQ19FWENMID8gT19FWENMIDogMCkKICAgICAgICAgICAgfCAoc2Vl a19yZWNvcmRzIHx8IChjb252ZXJzaW9uc19tYXNrICYgQ19OT1RSVU5DKSA/IDAgOiBPX1RS VU5DKSk7CiAKKyAgICAgIG9mZl90IHNpemU7CisgICAgICBpZiAoKElOVF9NVUxUSVBMWV9X UkFQViAoc2Vla19yZWNvcmRzLCBvdXRwdXRfYmxvY2tzaXplLCAmc2l6ZSkKKyAgICAgICAg ICAgfHwgSU5UX0FERF9XUkFQViAoc2Vla19ieXRlcywgc2l6ZSwgJnNpemUpKQorICAgICAg ICAgICYmICEoY29udmVyc2lvbnNfbWFzayAmIENfTk9UUlVOQykpCisgICAgICAgIGRpZSAo RVhJVF9GQUlMVVJFLCAwLAorICAgICAgICAgICAgIF8oIm9mZnNldCB0b28gbGFyZ2U6ICIK KyAgICAgICAgICAgICAgICJjYW5ub3QgdHJ1bmNhdGUgdG8gYSBsZW5ndGggb2Ygc2Vlaz0l IlBSSWRNQVgiIgorICAgICAgICAgICAgICAgIiAoJXRkLWJ5dGUpIGJsb2NrcyIpLAorICAg ICAgICAgICAgIHNlZWtfcmVjb3Jkcywgb3V0cHV0X2Jsb2Nrc2l6ZSk7CisKICAgICAgIC8q IE9wZW4gdGhlIG91dHB1dCBmaWxlIHdpdGggKnJlYWQqIGFjY2VzcyBvbmx5IGlmIHdlIG1p Z2h0CiAgICAgICAgICBuZWVkIHRvIHJlYWQgdG8gc2F0aXNmeSBhICdzZWVrPScgcmVxdWVz dC4gIElmIHdlIGNhbid0IHJlYWQKICAgICAgICAgIHRoZSBmaWxlLCBnbyBhaGVhZCB3aXRo IHdyaXRlLW9ubHkgYWNjZXNzOyBpdCBtaWdodCB3b3JrLiAgKi8KQEAgLTI0NzIsMTUgKzI1 MDcsNiBAQCBtYWluIChpbnQgYXJnYywgY2hhciAqKmFyZ3YpCiAKICAgICAgIGlmIChzZWVr X3JlY29yZHMgIT0gMCAmJiAhKGNvbnZlcnNpb25zX21hc2sgJiBDX05PVFJVTkMpKQogICAg ICAgICB7Ci0gICAgICAgICAgb2ZmX3Qgc2l6ZTsKLSAgICAgICAgICBpZiAoSU5UX01VTFRJ UExZX1dSQVBWIChzZWVrX3JlY29yZHMsIG91dHB1dF9ibG9ja3NpemUsICZzaXplKQotICAg ICAgICAgICAgICB8fCBJTlRfQUREX1dSQVBWIChzZWVrX2J5dGVzLCBzaXplLCAmc2l6ZSkp Ci0gICAgICAgICAgICBkaWUgKEVYSVRfRkFJTFVSRSwgMCwKLSAgICAgICAgICAgICAgICAg Xygib2Zmc2V0IHRvbyBsYXJnZTogIgotICAgICAgICAgICAgICAgICAgICJjYW5ub3QgdHJ1 bmNhdGUgdG8gYSBsZW5ndGggb2Ygc2Vlaz0lIlBSSWRNQVgiIgotICAgICAgICAgICAgICAg ICAgICIgKCV0ZC1ieXRlKSBibG9ja3MiKSwKLSAgICAgICAgICAgICAgICAgc2Vla19yZWNv cmRzLCBvdXRwdXRfYmxvY2tzaXplKTsKLQogICAgICAgICAgIGlmIChpZnRydW5jYXRlIChT VERPVVRfRklMRU5PLCBzaXplKSAhPSAwKQogICAgICAgICAgICAgewogICAgICAgICAgICAg ICAvKiBDb21wbGFpbiBvbmx5IHdoZW4gZnRydW5jYXRlIGZhaWxzIG9uIGEgcmVndWxhciBm aWxlLCBhCkBAIC0yNDkxLDE3ICsyNTE3LDIxIEBAIG1haW4gKGludCBhcmdjLCBjaGFyICoq YXJndikKICAgICAgICAgICAgICAgaW50IGZ0cnVuY2F0ZV9lcnJubyA9IGVycm5vOwogICAg ICAgICAgICAgICBzdHJ1Y3Qgc3RhdCBzdGRvdXRfc3RhdDsKICAgICAgICAgICAgICAgaWYg KGlmc3RhdCAoU1RET1VUX0ZJTEVOTywgJnN0ZG91dF9zdGF0KSAhPSAwKQotICAgICAgICAg ICAgICAgIGRpZSAoRVhJVF9GQUlMVVJFLCBlcnJubywgXygiY2Fubm90IGZzdGF0ICVzIiks Ci0gICAgICAgICAgICAgICAgICAgICBxdW90ZWFmIChvdXRwdXRfZmlsZSkpOwotICAgICAg ICAgICAgICBpZiAoU19JU1JFRyAoc3Rkb3V0X3N0YXQuc3RfbW9kZSkKLSAgICAgICAgICAg ICAgICAgIHx8IFNfSVNESVIgKHN0ZG91dF9zdGF0LnN0X21vZGUpCi0gICAgICAgICAgICAg ICAgICB8fCBTX1RZUEVJU1NITSAoJnN0ZG91dF9zdGF0KSkKKyAgICAgICAgICAgICAgICB7 CisgICAgICAgICAgICAgICAgICBlcnJvciAoMCwgZXJybm8sIF8oImNhbm5vdCBmc3RhdCAl cyIpLAorICAgICAgICAgICAgICAgICAgICAgICAgIHF1b3RlYWYgKG91dHB1dF9maWxlKSk7 CisgICAgICAgICAgICAgICAgICBleGl0X3N0YXR1cyA9IEVYSVRfRkFJTFVSRTsKKyAgICAg ICAgICAgICAgICB9CisgICAgICAgICAgICAgIGVsc2UgaWYgKFNfSVNSRUcgKHN0ZG91dF9z dGF0LnN0X21vZGUpCisgICAgICAgICAgICAgICAgICAgICAgIHx8IFNfSVNESVIgKHN0ZG91 dF9zdGF0LnN0X21vZGUpCisgICAgICAgICAgICAgICAgICAgICAgIHx8IFNfVFlQRUlTU0hN ICgmc3Rkb3V0X3N0YXQpKQogICAgICAgICAgICAgICAgIHsKICAgICAgICAgICAgICAgICAg IGludG1heF90IGlzaXplID0gc2l6ZTsKLSAgICAgICAgICAgICAgICAgIGRpZSAoRVhJVF9G QUlMVVJFLCBmdHJ1bmNhdGVfZXJybm8sCi0gICAgICAgICAgICAgICAgICAgICAgIF8oImZh aWxlZCB0byB0cnVuY2F0ZSB0byAlIlBSSWRNQVgiIGJ5dGVzIgotICAgICAgICAgICAgICAg ICAgICAgICAgICIgaW4gb3V0cHV0IGZpbGUgJXMiKSwKLSAgICAgICAgICAgICAgICAgICAg ICAgaXNpemUsIHF1b3RlYWYgKG91dHB1dF9maWxlKSk7CisgICAgICAgICAgICAgICAgICBl cnJvciAoMCwgZnRydW5jYXRlX2Vycm5vLAorICAgICAgICAgICAgICAgICAgICAgICAgIF8o ImZhaWxlZCB0byB0cnVuY2F0ZSB0byAlIlBSSWRNQVgiIGJ5dGVzIgorICAgICAgICAgICAg ICAgICAgICAgICAgICAgIiBpbiBvdXRwdXQgZmlsZSAlcyIpLAorICAgICAgICAgICAgICAg ICAgICAgICAgIGlzaXplLCBxdW90ZWFmIChvdXRwdXRfZmlsZSkpOworICAgICAgICAgICAg ICAgICAgZXhpdF9zdGF0dXMgPSBFWElUX0ZBSUxVUkU7CiAgICAgICAgICAgICAgICAgfQog ICAgICAgICAgICAgfQogICAgICAgICB9CkBAIC0yNTEyLDYgKzI1NDIsMTAgQEAgbWFpbiAo aW50IGFyZ2MsIGNoYXIgKiphcmd2KQogCiAgIGV4aXRfc3RhdHVzID0gZGRfY29weSAoKTsK IAorICBpbnQgc3luY19zdGF0dXMgPSBzeW5jaHJvbml6ZV9vdXRwdXQgKCk7CisgIGlmIChz eW5jX3N0YXR1cykKKyAgICBleGl0X3N0YXR1cyA9IHN5bmNfc3RhdHVzOworCiAgIGlmICht YXhfcmVjb3JkcyA9PSAwICYmIG1heF9ieXRlcyA9PSAwKQogICAgIHsKICAgICAgIC8qIFNw ZWNpYWwgY2FzZSB0byBpbnZhbGlkYXRlIGNhY2hlIHRvIGVuZCBvZiBmaWxlLiAgKi8KLS0g CjIuMzIuMAoK --------------cTC9yfwHvlPlTfuvnpFlpqsK-- From unknown Mon Jun 23 23:52:14 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 25 Feb 2022 12:24:08 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator