格式化usb并确认全零

Question

我想格式化我的 USB 驱动器并确认它已填充全零。为了格式化，这是我正在使用的命令： sudo mkfs.vfat -I /dev/sdb

如何通过命令行确认设备填充全零？

Answer 1

我也会把我的帽子扔到这里的戒指上。我喜欢使用的一种替代方法是scrub. 它位于存储库中，因此要从终端窗口输入：

sudo apt-get install scrub

scrub 支持许多不同类型的擦洗模式

Available patterns are:
  nnsa          3-pass   NNSA NAP-14.1-C
  dod           3-pass   DoD 5220.22-M
  bsi           9-pass   BSI
  usarmy        3-pass   US Army AR380-19
  random        1-pass   One Random Pass
  random2       2-pass   Two Random Passes
  schneier      7-pass   Bruce Schneier Algorithm
  pfitzner7     7-pass   Roy Pfitzner 7-random-pass method
  pfitzner33   33-pass   Roy Pfitzner 33-random-pass method
  gutmann      35-pass   Gutmann
  fastold       4-pass   pre v1.7 scrub (skip random)
  old           5-pass   pre v1.7 scrub
  dirent        6-pass   dirent
  fillzero      1-pass   Quick Fill with 0x00
  fillff        1-pass   Quick Fill with 0xff
  custom        1-pass   custom="string" 16b max, use escapes \xnn, \nnn, \\

要使用scrub全部填充驱动器，zeros请先确保未安装驱动器。然后运行以下行（-p表示要使用的模式）：

sudo scrub -p fillzero /dev/sdX

那么你应该看到这样的东西：

scrub: using Quick Fill with 0x00 patterns
scrub: please verify that device size below is correct!
scrub: scrubbing /dev/sdh 31260704768 bytes (~29GB)
scrub: 0x00    |.....                                           |

一些用于擦洗的图案应该有一个verify通行证，以确保擦洗通过。

如果您愿意，可以hexdump在末尾添加（如字节指挥官的答案）或任何其他答案以进行验证。

希望这可以帮助！

Answer 2

申请dd，并tr进行虚拟检查：

dd if=/dev/sdb | tr '\0' 0

申请dd和grep自动检查：

dd if=/dev/sdb | grep -zq . && echo non zero

上面的命令明显比下面的优化命令慢：

grep -zq . /dev/sdb && echo non zero

grep -z读取以空分隔的行。如果所有字节都为空，那么每一行都是空的，所以.永远不应该匹配。

当然，这不适用于格式化分区 - 格式化系统将使用一些字节并且它们将是非空的。

Answer 3

我的建议是hexdump。它将任何文件或设备的内容以十六进制格式显示为 16 字节的行，但如果两个后续行相等，则忽略它们。

这是 512 MB 文件的示例输出，该文件virtualdevice仅在我的硬盘驱动器的当前目录上填充零。最左边一列是十六进制表示的行的偏移​​量，以下8列是实际数据，分为两个字节（4个十六进制字符）：

$ hexdump ./virtualdevice 
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
20000000

表现：

我做出了努力，并通过所描述的示例文件（512 MB，仅包含二进制零，位于 HDD）的实际运行时间和 CPU 时间将我的解决方案与其他解决方案进行了比较。

我使用该time命令测量了每个解决方案两次，使用新清除的磁盘缓存，两次使用已经缓存的文件。时间名称等于time命令的时间名称，附加行CPU只是USER+SYS时间的总和。它可能会超过REAL时间，因为我运行的是双核机器。

对于大多数人来说，有趣的数字是REAL（从开始到结束的时间，就像用秒表测量的。这也包含其他进程的IO等待和CPU时间）和CPU（命令实际占用的CPU时间）。

概括：

最佳性能来自muru优化的第二个版本 ( grep -zq . DEVICE)，它使用极少的 CPU 处理时间。
Rank 2 share cmp /dev/zero DEVICE（kos的优化解决方案）和我自己的解决方案hexdump DEVICE。他们之间几乎没有区别。
将数据从ddto cmp（dd if=/dev/zero | cmp - DEVICE- kos的未优化解决方案）通过管道传输非常低效，管道似乎消耗了很多处理时间。
使用dd和grep显示迄今为止测试命令的最差性能。

结论：

尽管此类操作中最关键的部分是 IO 访问时间，但测试方法的处理速度和效率存在显着差异。

如果你很不耐烦，请使用muru的答案的第二个版本（grep -zq . DEVICE）！
但是您也可以使用第二个版本的kos答案 ( cmp /dev/zero DEVICE) 或我自己的 ( hexdump device)，因为它们的性能几乎一样好。
但是，我的方法的优点是您可以立即看到文件内容，并且可以估算与零不同的字节数以及它​​们所在的位置。但是，如果您有很多交替数据，则输出会变大并且可能会变慢。

无论如何你应该避免的是使用dd和管道。dd可以通过设置合适的缓冲区大小来提高性能，但为什么要以复杂的方式进行呢？

另请再次注意，测试是在我磁盘上的文件上完成的，而不是在实际设备上完成的。该文件也只包含零。两者都会影响性能。

以下是详细结果：

• hexdump ./virtualdevice （我自己的解决方案）：

          |    Uncached:      |    Cached:
   Time:  |  Run 1:   Run 2:  |  Run 1:   Run 2:
  --------+-------------------+------------------
     REAL |  7.689s   8.668s  |  1.868s   1.930s
     USER |  1.816s   1.720s  |  1.572s   1.696s
      SYS |  0.408s   0.504s  |  0.276s   0.220s
      CPU |  2.224s   2.224s  |  1.848s   1.916s
  

• dd if=./virtualdevice | grep -zq . && echo non zero（muru未优化的解决方案）：

          |    Uncached:      |    Cached:
   Time:  |  Run 1:   Run 2:  |  Run 1:   Run 2:
  --------+-------------------+------------------
     REAL |  9.434s  11.004s  |  8.802s   9.266s
     USER |  2.264s   2.364s  |  2.480s   2.528s
      SYS | 12.876s  12.972s  | 12.676s  13.300s
      CPU | 15.140s  15.336s  | 15.156s  15.828s
  

• grep -zq . ./virtualdevice && echo non zero（muru的优化方案）：

          |    Uncached:      |    Cached:
   Time:  |  Run 1:   Run 2:  |  Run 1:   Run 2:
  --------+-------------------+------------------
     REAL |  8.763s   6.485s  |  0.770s   0.833s
     USER |  0.644s   0.612s  |  0.528s   0.544s
      SYS |  0.440s   0.476s  |  0.236s   0.264s
      CPU |  1.084s   1.088s  |  0.764s   0.808s
  

• dd if=/dev/zero | cmp - ./virtualdevice（kos的解决方案未优化）：

          |    Uncached:      |    Cached:
   Time:  |  Run 1:   Run 2:  |  Run 1:   Run 2:
  --------+-------------------+------------------
     REAL |  7.678s   6.539s  |  3.151s   3.147s
     USER |  2.348s   2.228s  |  2.164s   2.324s
      SYS |  3.672s   3.852s  |  3.792s   3.516s
      CPU |  6.020s   6.080s  |  5.956s   5.840s
  

• cmp /dev/zero ./virtualdevice（kos的解决方案优化）：

          |    Uncached:      |    Cached:
   Time:  |  Run 1:   Run 2:  |  Run 1:   Run 2:
  --------+-------------------+------------------
     REAL |  6.340s   9.183s  |  1.660s   1.660s
     USER |  1.356s   1.384s  |  1.216s   1.288s
      SYS |  0.640s   0.596s  |  0.428s   0.360s
      CPU |  1.996s   1.980s  |  1.644s   1.648s
  

使用的命令：

对于所有四个测试，我运行了两次以下过程以减少不准确，替换<COMMAND>为每个表格标题中的确切命令。

• 让内核删除所有磁盘缓存：

  sync && echo 3 | sudo tee /proc/sys/vm/drop_caches
  

• 第一次定时运行（未缓存），文件在此期间被加载到缓存中：

  time <COMMAND>
  

• 第二次定时运行（缓存）。这次大部分数据是从内存中的磁盘缓存中获取的，因此比直接访问磁盘要快得多：

  time <COMMAND>
  

Answer 4

使用cmp（感谢 muru 指出使用管道的愚蠢之处）：

sudo cmp /dev/zero /dev/sdX

如果你得到这样的输出：

cmp: EOF on /dev/sdX

驱动器是零填充的。

% dd if=/dev/zero of=foo iflag=fullblock bs=1M count=1 && sync
1+0 records in
1+0 records out
1048576 bytes (1,0 MB) copied, 0,00226603 s, 463 MB/s
% cmp /dev/zero foo
cmp: EOF on foo