格式化USB並確認全零

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

一些用於擦洗的圖案應該有一個verifypass，以確保擦洗通過。

如果您願意，可以將hexdump（如 Byte Commander 的答案）或任何其他答案添加到末尾以進行驗證。

希望這可以幫助！

Answer

我也將在這裡投入我的帽子。我喜歡使用的一種替代方法是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    |.....                                           |

一些用於擦洗的圖案應該有一個verifypass，以確保擦洗通過。

如果您願意，可以將hexdump（如 Byte Commander 的答案）或任何其他答案添加到末尾以進行驗證。

希望這可以幫助！

Question 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

適用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讀取以空分隔的行。如果所有位元組都為空，則每一行都是空的，因此.永遠不應該匹配。

當然，對於格式化分割區來說，情況並非如此 - 格式系統將使用一些字節，並且它們將是非空的。

Question 3

我的建議是hexdump。它將任何檔案或裝置的內容以十六進位格式顯示為 16 位元組的行，但如果後續兩行相等，則會忽略它們。

下面是 512 MB 檔案的範例輸出virtualdevice，該檔案僅在 HDD 的目前目錄上以零填充。最左邊的列是以十六進位表示法表示的行的偏移量，接下來的 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時間）。

概括：

最好的表現有穆魯最佳化的第二個版本 ( grep -zq . DEVICE) 使用的 CPU 處理時間極少。
排名 2 份額cmp /dev/zero DEVICE(科斯'優化的解決方案）和我自己的解決方案hexdump DEVICE。他們之間幾乎沒有區別。
透過管道將資料從dd傳輸到cmp( dd if=/dev/zero | cmp - DEVICE-科斯'未優化的解決方案）效率非常低，管道似乎消耗了很多處理時間。
使用dd和grep顯示了迄今為止測試命令的最差性能。

結論：

儘管此類操作最關鍵的部分是 IO 存取時間，但測試方法的處理速度和效率存在顯著差異。

如果您非常不耐煩，請使用第二個版本穆魯的答案是( grep -zq . DEVICE)！
但您也可以使用第二個版本科斯' 回答 ( cmp /dev/zero DEVICE) 或我自己的 ( hexdump device)，因為它們的表現幾乎一樣好。
但是，我的方法的優點是您可以立即看到文件內容，並且可以估算與零不同的位元組數以及它們所在的位置。如果你有很多交替數據，輸出會變大並且可能會減慢。

無論如何，你應該避免使用ddand 管道。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（穆魯的未最佳化解決方案）：

        |    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（穆魯的優化方案）：

        |    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（科斯' 解決方案未最佳化）：

        |    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（科斯' 解決方案優化）：

        |    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>
```
第二次定時運行（快取）。這次大部分資料是從 RAM 中的磁碟快取中取得的，因此比直接存取磁碟時要快得多：
```
time <COMMAND>
```

Answer