USBをフォーマットし、すべてゼロであることを確認する

Question 1

私もここで参加したいと思います。私が好んで使う代替手段の 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検証のために (Byte Commander の回答のように) またはその他の回答を最後に追加できます。

お役に立てれば！

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検証のために (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ヌルで区切られた行を読み取ります。すべてのバイトがヌルの場合、各行は空なので、.一致しません。

もちろん、これはフォーマットされたパーティションには当てはまりません。フォーマットシステムはいくつかのバイトを使用し、それらは null ではありません。

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ヌルで区切られた行を読み取ります。すべてのバイトがヌルの場合、各行は空なので、.一致しません。

もちろん、これはフォーマットされたパーティションには当てはまりません。フォーマットシステムはいくつかのバイトを使用し、それらは null ではありません。

Question 3

私の提案はですhexdump。これは、任意のファイルまたはデバイスの内容を 16 進形式で 16 バイトの行として表示しますが、後続の 2 行が同じ場合は省略します。

以下は、HDD の現在のディレクトリにのみゼロで埋められた 512 MB のファイルの出力例ですvirtualdevice。左端の列は 16 進表記の行のオフセットで、次の 8 列は実際のデータで、2 バイト (4 つの 16 進文字) にグループ化されています。

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

パフォーマンス：

私は努力して、記載されているサンプルファイル (512 MB、バイナリゼロのみを含む、HDD 上にある) の実際の実行時間と CPU 時間で自分のソリューションを他のソリューションと比較しました。

timeディスクキャッシュをクリアした状態でコマンドを 2 回実行し、ファイルがすでにキャッシュされている状態で 2 回実行して、すべてのソリューションを測定しました。時間名はtimeコマンドの名前と同じで、追加の行は+時間CPUの合計です。デュアルコアマシンを実行しているため、時間を超える場合があります。USERSYSREAL

ほとんどの人にとって、興味深い数字はREAL(ストップウォッチで計測したような開始から終了までの時間。これには IO 待機時間と他のプロセスの CPU 時間も含まれます) とCPU(コマンドによって実際に占有されている CPU 時間) です。

まとめ：

最高のパフォーマンスはムルの最適化された第2バージョン（grep -zq . DEVICE）は、CPU処理時間を非常に少なくします。
ランク2シェアcmp /dev/zero DEVICE（コス' 最適化されたソリューション) と私の独自のソリューションですhexdump DEVICE。両者の間にはほとんど違いはありません。から( - )
にデータをパイプするには、ddcmpdd if=/dev/zero | cmp - DEVICEコス' 最適化されていないソリューションは非常に非効率的で、パイピングに多くの処理時間が消費されるようです。と
を使用するとdd、grepテストされたコマンドの中で最悪のパフォーマンスが示されます。

結論：

このような操作で最も重要な部分は IO アクセス時間ですが、テストされたアプローチの処理速度と効率には大きな違いがあります。

非常にせっかちな場合は、2番目のバージョンを使用してくださいムルの答え（grep -zq . DEVICE）です！
しかし、2番目のバージョンのコス' の回答 ( 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（ムルの最適化されていないソリューション):

        |    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

使用されるコマンド:

4つのテストすべてで次の手順を実行しました2回不正確さを減らすために、<COMMAND>各表の見出しからの正確なコマンドに置き換えます。

カーネルにすべてのディスクキャッシュを削除させます。
```
sync && echo 3 | sudo tee /proc/sys/vm/drop_caches
```
最初の実行時間 (キャッシュなし)、ファイルはこの間にキャッシュにロードされます。
```
time <COMMAND>
```
2 回目の時間指定実行 (キャッシュ済み)。今回はほとんどのデータが RAM 内のディスクキャッシュから取得されるため、ディスクに直接アクセスする場合よりもはるかに高速です。
```
time <COMMAND>
```

Answer

私の提案はですhexdump。これは、任意のファイルまたはデバイスの内容を 16 進形式で 16 バイトの行として表示しますが、後続の 2 行が同じ場合は省略します。

以下は、HDD の現在のディレクトリにのみゼロで埋められた 512 MB のファイルの出力例ですvirtualdevice。左端の列は 16 進表記の行のオフセットで、次の 8 列は実際のデータで、2 バイト (4 つの 16 進文字) にグループ化されています。

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

パフォーマンス：

私は努力して、記載されているサンプルファイル (512 MB、バイナリゼロのみを含む、HDD 上にある) の実際の実行時間と CPU 時間で自分のソリューションを他のソリューションと比較しました。

timeディスクキャッシュをクリアした状態でコマンドを 2 回実行し、ファイルがすでにキャッシュされている状態で 2 回実行して、すべてのソリューションを測定しました。時間名はtimeコマンドの名前と同じで、追加の行は+時間CPUの合計です。デュアルコアマシンを実行しているため、時間を超える場合があります。USERSYSREAL

ほとんどの人にとって、興味深い数字はREAL(ストップウォッチで計測したような開始から終了までの時間。これには IO 待機時間と他のプロセスの CPU 時間も含まれます) とCPU(コマンドによって実際に占有されている CPU 時間) です。

まとめ：

最高のパフォーマンスはムルの最適化された第2バージョン（grep -zq . DEVICE）は、CPU処理時間を非常に少なくします。
ランク2シェアcmp /dev/zero DEVICE（コス' 最適化されたソリューション) と私の独自のソリューションですhexdump DEVICE。両者の間にはほとんど違いはありません。から( - )
にデータをパイプするには、ddcmpdd if=/dev/zero | cmp - DEVICEコス' 最適化されていないソリューションは非常に非効率的で、パイピングに多くの処理時間が消費されるようです。と
を使用するとdd、grepテストされたコマンドの中で最悪のパフォーマンスが示されます。

結論：

このような操作で最も重要な部分は IO アクセス時間ですが、テストされたアプローチの処理速度と効率には大きな違いがあります。

非常にせっかちな場合は、2番目のバージョンを使用してくださいムルの答え（grep -zq . DEVICE）です！
しかし、2番目のバージョンのコス' の回答 ( 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（ムルの最適化されていないソリューション):

        |    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

使用されるコマンド:

4つのテストすべてで次の手順を実行しました2回不正確さを減らすために、<COMMAND>各表の見出しからの正確なコマンドに置き換えます。

カーネルにすべてのディスクキャッシュを削除させます。
```
sync && echo 3 | sudo tee /proc/sys/vm/drop_caches
```
最初の実行時間 (キャッシュなし)、ファイルはこの間にキャッシュにロードされます。
```
time <COMMAND>
```
2 回目の時間指定実行 (キャッシュ済み)。今回はほとんどのデータが RAM 内のディスクキャッシュから取得されるため、ディスクに直接アクセスする場合よりもはるかに高速です。
```
time <COMMAND>
```

Question 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

Answer

使用方法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

USBをフォーマットし、すべてゼロであることを確認する

答え1

答え2

答え3

パフォーマンス：

答え4

関連情報