X-Recipient: archive-cygwin AT delorie DOT com
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 8EC8B3851C09
Authentication-Results: sourceware.org;
 dmarc=none (p=none dis=none) header.from=pdinc.us
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=jpyeron AT pdinc DOT us
DKIM-Filter: OpenDKIM Filter v2.11.0 mail1.pdinc.us 05SHo6EE018543
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pdinc.us; s=default;
 t=1593366607; bh=utvhDICVb1zb/L4aM0p/fNdST8AG3cLRvYJkwIUZQOE=;
 h=From:To:References:In-Reply-To:Subject:Date:From;
 b=ProkcHl8KnwSZJJVkQeh5a1gw54//Ho/VaQHDBabs+uKIpl89SnH69MXDxjpuGFy4
 Qgvfl6smZi9PcBnA1LJPw9hzhGgxf6r1Ra2+YiSMxftKsyIq/k2cWvxDeX5vA+ooaA
 I/EexHXV6lWifESv564qYSHfYlvadraU87TjYBUv2tGr5Y0XXcQjaYSB/Ad1YA/41k
 ovOwGD3t88SXyzjfDu1ou/Jm365eBh82osnDsXe1RbEG2so2ULkTnuJc1a8uTJV3KV
 kdGn42nozqgWe/vVxtcGjtjNpJYiinA5OnIkN8aC277PsTDcoQNOvsdTbWVed5CFZr
 99CPN7hokjo3g==
From: "Jason Pyeron" <jpyeron AT pdinc DOT us>
To: <cygwin AT cygwin DOT com>
References: <DB7PR01MB5193A18F1D947ED4C276CD25D5980 AT DB7PR01MB5193 DOT eurprd01 DOT prod DOT exchangelabs DOT com>
 <1d1801d64677$bea56050$3bf020f0$@pdinc.us>
 <DB7PR01MB5193CC1C7630FB13B81B9DBAD5980 AT DB7PR01MB5193 DOT eurprd01 DOT prod DOT exchangelabs DOT com>
 <60bf1507-4edb-a03f-ec14-07e1ab7f0d94 AT cs DOT umass DOT edu>
 <DB7PR01MB519396195ADB3E3E1217B22BD5940 AT DB7PR01MB5193 DOT eurprd01 DOT prod DOT exchangelabs DOT com>
 <CAKNeuBqZpacuUwTD6U+kKPGOO052VYhpRnttm=HYr7m+OT7tiA AT mail DOT gmail DOT com>
 <DB7PR01MB519371C6CAE2D3CFFEF41DCAD5940 AT DB7PR01MB5193 DOT eurprd01 DOT prod DOT exchangelabs DOT com>
 <1814912576 DOT 20200624132126 AT yandex DOT ru>
 <5c9c5b44-c8a6-a075-705e-1761533cc966 AT t-online DOT de>
In-Reply-To: <5c9c5b44-c8a6-a075-705e-1761533cc966@t-online.de>
Subject: RE: [cygwin] DD bug fails to wipe last 48 sectors of a disk
Date: Sun, 28 Jun 2020 13:50:16 -0400
Message-ID: <00f601d64d74$959826d0$c0c87470$@pdinc.us>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 15.0
Content-Language: en-us
Thread-Index: AQGscau3vmYRj+s+e2PTQd4MF23JZQNbIR/1ATPrTR8BvLqaegH1Mf0MASBnz4oCdZANkQB69/suAf+oHKyoz3IhsA==
X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00, DKIM_SIGNED,
 DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_INFOUSMEBIZ, SPF_HELO_PASS,
 SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
 server2.sourceware.org
X-BeenThere: cygwin AT cygwin DOT com
X-Mailman-Version: 2.1.29
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Archive: <https://cygwin.com/pipermail/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe: <http://cygwin.com/mailman/listinfo/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Sender: "Cygwin" <cygwin-bounces AT cygwin DOT com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by delorie.com id 05SHoeGR014857

> -----Original Message-----
> From: Christian Franke
> Sent: Sunday, June 28, 2020 10:35 AM
> 
> Andrey Repin wrote:
> >
> >> dd if=/dev/zero of=/dev/sda iflag=fullblock bs=4M status=progress
> 
> The root of the problem is that the Windows WriteFile() function
> apparently does not support truncated writes at EOM. If seek_position +
> write_size > disk_size, then WriteFile() does nothing and returns an error.
> 
> 
> > oflag=direct
> >
> > Although I'm unsure how Cygwin/Windows handles it. But without this flag, the
> > write is cached, and the problem may be outside dd, or even Cygwin.
> 
> If 'oflag=direct' is used, dd passes O_DIRECT flag to open() call of
> output file. Cygwin's open() function then passes
> FILE_NO_INTERMEDIATE_BUFFERING to NtCreateFile() and the write()
> function calls WriteFile() directly with original address and size.
> 
> Without O_DIRECT, Cygwin ensures that address and size passed to
> WriteFile() are both aligned to sector size. All writes are then done
> through a 64KiB internal buffer.
> 
> As a consequence, oflag=direct in the above dd command may increase
> speed but would also let the final 4MiB WriteFile() fail. Without
> oflag=direct, only the last 64KiB WriteFile() fails.
> 
> To clear the last sectors of the disk, use an appropriate small block
> size. I did this several times with Cygwin 'dd seek=... bs=512 ...' to
> get rid of Intel RST RAID metadata.

The reason I have never encountered this is because I use a block size which is the largest practical GCD of the drive size and 512 bytes (typically between 32 MB and 64 MB).

E.g. I have a drive that is 160,041,885,696 bytes, which divides 312,581,808 times evenly into 512. I would use a block size of ‭39,072,726‬ bytes, which gives 4,096 blocks to write.

-Jason

--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple