web-dev-qa-db-ja.com

USBをフォーマットし、すべてゼロを確認します

USBドライブをフォーマットし、すべてゼロで埋められていることを確認します。書式設定のために、これは私が使用しているコマンドです：Sudo mkfs.vfat -I /dev/sdb

コマンドラインでデバイスがすべてゼロで埋められていることを確認するにはどうすればよいですか？

command-lineusbformatdd
7
homeGrown

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

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

9
muru

ここでもリングに帽子を投げます。私が使用するのが好きな代替手段は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の回答のように）またはその他の回答を検証のために最後に追加できます。

お役に立てれば！

11
Terrance

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
5
kos

私の提案はhexdumpです。ファイルまたはデバイスのコンテンツを16バイトの行として16進形式で表示しますが、2つの後続の行が等しい場合は、それらを省略します。

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

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

性能：

説明したサンプルファイルの実際の実行時間とCPU時間（HDDにあるバイナリゼロのみを含む512 MB）で他のソリューションと比較して努力しました。

timeコマンドを使用して、すべてのソリューションを、新しくクリアされたディスクキャッシュで2回、ファイルが既にキャッシュされている状態で2回測定しました。時間名はtimeコマンドのものと等しく、追加の行CPUはUSER + SYS回の合計です。デュアルコアマシンを実行しているため、REAL時間を超える可能性があります。

ほとんどの人にとって、興味深い数値はREAL（ストップウォッチで測定した場合の開始から終了までの時間。これにはIO待機および他のプロセスのCPU時間も含まれます）およびCPU（コマンドが実際に占有しているCPU時間）。

概要：

最高のパフォーマンスにはmurの最適化された2番目のバージョン（grep -zq . DEVICE）があり、CPU処理時間が非常に少なくなります。
ランク2はcmp /dev/zero DEVICE（kos '最適化ソリューション）と私自身のソリューションhexdump DEVICEを共有します。それらの間にほとんど違いはありません。
データをddからcmpにパイプする（dd if=/dev/zero | cmp - DEVICE-kos '最適化されていないソリューション）は非常に非効率的であるため、パイプの消費量が多いようです処理時間。
ddおよびgrepを使用すると、テストしたコマンドのパフォーマンスがはるかに悪いことがわかります。

結論：

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

あなたが非常に短気である場合、murの答え（grep -zq . DEVICE）の2番目のバージョンを使用してください！
ただし、kos 'answer（cmp /dev/zero DEVICE）の2番目のバージョンか、独自の（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（murの最適化されていないソリューション）：

            |    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（murの最適化されたソリューション）：

            |    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

使用するコマンド：

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

  • カーネルにすべてのディスクキャッシュをドロップさせます。

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

  • 初回の実行（キャッシュなし）の場合、この間にファイルがキャッシュにロードされます。

    time <COMMAND>

  • 2回目の実行（キャッシュ）。今回は、ほとんどのデータがRAMのディスクキャッシュから取得されるため、ディスクに直接アクセスする場合よりもはるかに高速です。

    time <COMMAND>
5
Byte Commander