From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail1.pdinc.us (mail.pdinc.us [67.90.184.27]) by sourceware.org (Postfix) with ESMTPS id 8EC8B3851C09 for ; Sun, 28 Jun 2020 17:50:09 +0000 (GMT) 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@pdinc.us Received: from lovegrove (nsa1.pdinc.us [67.90.184.2]) (authenticated bits=0) by mail1.pdinc.us (8.14.4/8.14.4) with ESMTP id 05SHo6EE018543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 28 Jun 2020 13:50:07 -0400 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" To: References: <1d1801d64677$bea56050$3bf020f0$@pdinc.us> <60bf1507-4edb-a03f-ec14-07e1ab7f0d94@cs.umass.edu> <1814912576.20200624132126@yandex.ru> <5c9c5b44-c8a6-a075-705e-1761533cc966@t-online.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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2020 17:50:12 -0000 > -----Original Message----- > From: Christian Franke > Sent: Sunday, June 28, 2020 10:35 AM >=20 > Andrey Repin wrote: > > > >> dd if=3D/dev/zero of=3D/dev/sda iflag=3Dfullblock bs=3D4M = status=3Dprogress >=20 > 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. >=20 >=20 > > oflag=3Ddirect > > > > 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. >=20 > If 'oflag=3Ddirect' 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. >=20 > 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. >=20 > As a consequence, oflag=3Ddirect in the above dd command may increase > speed but would also let the final 4MiB WriteFile() fail. Without > oflag=3Ddirect, only the last 64KiB WriteFile() fails. >=20 > To clear the last sectors of the disk, use an appropriate small block > size. I did this several times with Cygwin 'dd seek=3D... bs=3D512 = ...' 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 = =E2=80=AD39,072,726=E2=80=AC bytes, which gives 4,096 blocks to write. -Jason