我在尝试按照建议使用普通的 dm-crypt 擦除整个磁盘时偶然发现了这一点，例如，这里 (arch linux wiki)：
# cryptsetup open --type plain -d /dev/urandom /dev/sda to_be_wiped
# dd if=/dev/zero of=/dev/mapper/to_be_wiped status=progress
编辑：参见下文，我检查了所有设置是否正确
我检查了磁盘的前几个字节/dev/sda，发现上面有一些旧数据，因此我尝试了以下操作（运行上述dd命令 2 小时后）：
A.1 使用以下方法手动擦除磁盘的第一部分/dev/zero：
dd if=/dev/zero of=/dev/sda bs=512 count=2
A.2 读取磁盘的第一部分以验证其是否已归零。它是：
dd if=/dev/sda bs=512 count=2 | xxd
A.3 读取映射设备的第一部分。（这似乎也被归零了 -为什么？这不应该是“解密的零”吗？）
dd if=/dev/mapper/to_be_wiped bs=512 count=2 | xxd
之后，我做了以下事情：
B.1 将映射设备归零/dev/mapper/to_be_wiped：
dd if=/dev/zero of=/dev/mapper/to_be_wiped bs=512 count=2
B.2 按照上面的 A.2 读/dev/sda- 仍然为零（为什么？这不应该是加密的零，即随机数据吗？）。
B.3 按照上述 A.3 读取加密设备 - 也是零（如预期）。
即使syncing 也不会改变我的硬盘的结果。所以我在一个文件上尝试了同样的操作。这里一切似乎都按预期工作。所以我很想知道...
我的（主要）问题是：
- 我的错误在哪里？我做错了什么吗？我假设是逐扇区加密，因此在第一种情况下 3. 不应归零，而在第二种情况下 2 应随机化。
这自然而然地引出了后续问题
- 那么，是否可以安全地假设使用此方法可以擦除磁盘？
什么可以帮助实现这一目标：
- 正如手册中所述，普通 dm-crypt 设备的映射不是逐个扇区进行的吗？
- 对于 dm-crypt 使用文件和使用磁盘有什么区别吗？
编辑：按照 Xen2050 的建议，我验证了所有设置均正确：
# cryptsetup -v status to_be_wiped
/dev/mapper/to_be_wiped is active.
type: PLAIN
cipher: aes-cbc-essiv:sha256
keysize: 256 bits
key location: dm-crypt
device: /dev/sda
sector size: 512
offset: 0 sectors
size: 976773168 sectors
mode: read/write
Command successful.
# dmsetup ls --target crypt
to_be_wiped (254, 0)
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
loop0 7:0 0 487.9M 1 loop /run/archiso/sfs/airootfs
sda 8:0 0 465.8G 0 disk
└─to_be_wiped 254:0 0 465.8G 0 crypt
[...]
循环设备来自我使用的 arch linux live stick，我从中删除了其他现有磁盘lsblk。
编辑2：添加了输出的简短示例（如下）。如果不关闭 dm-crypt，它是否不会写入磁盘？如果是，为什么以及如何更改它？请看以下内容：
root@archiso ~ # dd if=/dev/zero of=/dev/sda bs=8 count=2 status=none
root@archiso ~ # xxd -l 16 /dev/sda
00000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................
root@archiso ~ # cryptsetup open --type plain -d /dev/urandom /dev/sda to_be_wiped
root@archiso ~ # xxd -l 16 /dev/mapper/to_be_wiped
00000000: df52 0cc9 082a 0de2 1df7 b55f 7626 c45b .R...*....._v&.[
root@archiso ~ # dd if=/dev/zero of=/dev/mapper/to_be_wiped bs=8 count=1 status=none
root@archiso ~ # xxd -l 16 /dev/mapper/to_be_wiped
00000000: 0000 0000 0000 0000 1df7 b55f 7626 c45b ..........._v&.[
root@archiso ~ # xxd -l 16 /dev/sda
00000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................
root@archiso ~ # sync
root@archiso ~ # grep -e Dirty: -e Writeback /proc/meminfo
Dirty: 0 kB
Writeback: 0 kB
WritebackTmp: 0 kB
root@archiso ~ # cat /sys/dev/block/8:0/stat
1153 0 49276 19035 9 0 72 6763 0 19010 25747 0 0 0 0
root@archiso ~ # xxd -l 16 /dev/sda
00000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................
root@archiso ~ # cryptsetup close to_be_wiped
root@archiso ~ # xxd -l 16 /dev/sda
00000000: c6d2 1e9b abf4 16a2 7d1a b1bd 8a28 63d8 ........}....(c.
编辑3：我做了与 EDIT2 类似的测试，但数据更多，结果如下：除非关闭，否则普通的 dm-crypt 不会写入前半兆字节。如果我关闭映射设备 ( cryptsetup close to_be_wiped)，则所有内容都是随机的。没有任何解释的奇怪东西，尤其是因为文件似乎被正确/立即处理 - 有人有吗？
编辑4：我从二月份开始cryptsetup 2.0.6就在 arch iso 上使用它2019.02.01。
答案1
第一个命令应该有效，它们与cryptsetup 常见问题解答 (2.19)。使用文件而不是设备会使用中间循环文件，但其他方面相同。
但我怀疑映射的设备名称有错误。如果不存在，dd将会很乐意创建一个新文件/dev/mapper/，并且似乎没有任何内容被写入您的硬盘驱动器。
- 文件夹中现在有什么
ls -al /dev/mapper/？ 运行初始 cryptsetup 命令后，您是否使用以下命令进行验证：
sudo cryptsetup -v status to_be_wipedsudo dmsetup ls --target cryptlsblk
您是否监控过硬盘驱动器，以查看第一个驱动器是否实际写入了任何内容
dd（使用系统监视器来区分对 sda 驱动器的写入，/我知道conky可以）？sda 驱动器或系统驱动器是否发出任何噪音或亮起，如果可以注意到的话？
[只是想知道，但sda您的系统驱动器不是吗？]
在您的第一个 3. 问题中（仅供参考，问题编号是有问题的，有三个单独的“2。”），您刚刚在 sda 的开头写入了零，因此读回零是意料之中的事。
在您的第二个例子中，dd尝试写入/dev/mapper而不是内部文件，但是这应该出错，dd: failed to open '/dev/mapper': Is a directory所以我假设这是 Q 中的拼写错误。
更新 EDIT2 & 3 后
嗯，一切看起来都应该正常工作，但就是不行……据我所知，cryptsetup 的 close 命令不应该写入任何内容（只是“忘记”密钥并停止加密/解密）。只有模糊的关联，但如果 LUKS 在那里使用标头，它通常会保留前 1M 或 2M。
开始看起来像是某个东西中的错误...我会尝试使用不同的实时 ISO / 内核 / 发行版，至少缩小范围，看看是否只是特定的实时 ISO 或您的驱动器。
答案2
这似乎是一个缓存问题，如下所示：
root@archiso ~ # dd if=/dev/zero of=/dev/sda bs=32 count=2 % zeroing sda
2+0 records in
2+0 records out
64 bytes copied, 0.75095 s, 0.1 kB/s
root@archiso ~ # dd if=/dev/sda bs=32 count=2 status=none | xxd % verify result
00000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
root@archiso ~ # cryptsetup open --type=plain -d /dev/urandom /dev/sda to_be_wiped % open as plain dm-crypt
root@archiso ~ # dd if=/dev/mapper/to_be_wiped bs=32 count=2 status=none | xxd % show to_be_wiped
00000000: 747a 1b84 3847 b8f2 7bae ec41 a302 05d2 tz..8G..{..A....
00000010: c866 4305 7293 4765 99eb c88b a0da 2548 .fC.r.Ge......%H
00000020: c866 4305 7293 4765 99eb c88b a0da 2548 .fC.r.Ge......%H
00000030: c866 4305 7293 4765 99eb c88b a0da 2548 .fC.r.Ge......%H
root@archiso ~ # dd if=/dev/zero bs=32 count=2 of=/dev/mapper/to_be_wiped % zeroing to_be_wiped
2+0 records in
2+0 records out
64 bytes copied, 0.749869 s, 0.1 kB/s
root@archiso ~ # dd if=/dev/mapper/to_be_wiped bs=32 count=2 status=none | xxd % verify result
00000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
root@archiso ~ # dd if=/dev/sda bs=32 count=2 status=none | xxd % sda should be randomized, check that
00000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
root@archiso ~ # dd of=/dev/sda oflag=nocache conv=notrunc,fdatasync count=0 % since sda is not randomized, drop cache manually
0+0 records in
0+0 records out
0 bytes copied, 0.000501071 s, 0.0 kB/s
root@archiso ~ # dd if=/dev/sda bs=32 count=2 status=none | xxd % check sda again
00000000: 077d 0039 4781 2f67 a50c 413f 8ad7 b06d .}.9G./g..A?...m
00000010: 99b2 2517 04cc 04e6 69a5 e806 44ba f902 ..%.....i...D...
00000020: 4208 ff50 72d7 225b e0ce 0346 a1c6 3ac0 B..Pr."[...F..:.
00000030: fab3 b9f9 5218 faf3 4392 50ad 8c71 1f37 ....R...C.P..q.7
所以，丢弃缓存后，显示的是随机数据。cryptsetup close但我不知道为什么发布后会丢弃缓存。
答案3
我在使用 plain-wipe 时遇到了类似的问题cryptsetup。根据 的说法，它似乎保持了驱动器分区表的完好无损lsblk。
hdparm -z似乎已经解决了，尽管我不确定如何解决。
-z Force a kernel re-read of the partition table of the specified device(s).
它是 Seagate 2TB，可能带有 SMR。