ddのibs/obs/bsの目的

Question

Linuxマシン上のファイルにファイルシステムを作成するスクリプトがあります。ファイルシステムを作成するには、bs = xオプションで 'dd'を使用し、/ dev/zeroから読み取り、ファイルに書き込みます。通常、ibs/obs/bsを指定することは、特定のブロックサイズの制約があるため、実際のハードウェアデバイスから読み取る場合に便利です。しかし、この場合、仮想デバイスからの読み取りとファイルへの書き込みのために、 'bs = x bytes'オプションを使用することはありません。ここで私の理解は間違っていますか？ （このファイルシステムは後でqemu VMを起動するために使用されます）

Answer 1

ブロックサイズは、一度に読み書きされるバイト数です。おそらく、ブロックサイズの単位で指定されたcount=オプションがあります。 skip=またはseek=オプションがある場合、それらもブロックサイズ単位になります。しかし、通常のファイルを読み書きしているときにディスクエラーがなければ、それらのパラメータをそれに応じてスケーリングすることができ、それらはまだ整数である限り、ブロックサイズは重要ではありません。しかし、特定のサイズは他よりも効率的です。

Answer 2

/dev/zeroから読み込む場合は問題ありません。 ibs/obs/bsは、一度に読み取られるバイト数を指定します。バイトがオペレーティングシステムで読み書きされる方法に基づいて数値を選択すると便利です。たとえば、Linuxは通常、4096バイトのチャンクでハードドライブから読み取ります。基礎となるハードウェアがどのように読み書きするかについて少なくともいくつかの考えがある場合は、ibs/obs/bsを指定することをお勧めします。ちなみに、bsを指定すると、ibsとobsに指定したものが上書きされます。

Answer 3

ブロックサイズを理解するには、テープドライブに精通している必要があります。あなたがテープドライブに興味がないなら、例えばあなたがこれを使うつもりはないと思うなら、今すぐ眠ることができます。

60年代、70年代、80年代の映画のテープドライブを覚えていますか？リールがどこを回っていたのか？ ExabyteやQIC - 1/4インチのカートリッジテープではありません。あなたの良い旧式のリールツーリールの半インチテープドライブ？それらについては、ブロックサイズが重要です。

テープ上のデータはブロック単位で書き込まれました。各ブロックは、レコード間ギャップによって次のブロックから分離された。

----+-------+-----+-------+-----+---- 
... | block | IRG | block | IRG | ... 
----+-------+-----+-------+-----+---- 

テープドライブのハードウェアおよびソフトウェアによっては、さまざまな問題が発生する可能性があります。たとえば、テープが5120バイトのブロックサイズで書き込まれていて、ブロックサイズが512バイトのテープを読み取った場合、テープドライブは最初のブロックを読み込み、512バイトを返し、残りのバイトを破棄しますデータ;次のブロックで次の読み取りが開始されます。逆に、テープが512バイトのブロックサイズで書き込まれていて、5120バイトのブロックを要求した場合、短い読み込みが行われます。それぞれの読み取りは512バイトしか返しません。ソフトウェアが注意を払っていなければ、あなたはゴミを読んでいます。テープドライブがブロックを読み取って速度を落とす速度を上げなければならないという問題もありました。 ASCIIアートは、IRGがデータブロックよりも小さいことを示唆しています。必ずしもそうではありませんでした。そして、1ブロックを読み、IRGをオーバーシュートし、逆方向に巻き戻して次のブロックに到達し、再び前進を開始するのに時間がかかりました。テープドライブにデータをバッファリングするメモリがない場合、安価なテープドライブではテープドライブのパフォーマンスに深刻な影響を与える可能性があります。

戦争の話：少し近代的なテープドライブを備えた新しいマシンで作業を準備しました。わかりやすいブロックサイズのないtarを使ってテープを書きました（デフォルトは512バイトです）。これはソフトウェアの大部分でした - ああ、合計で100 MB未満であったに違いありません。マシンはモダンなので、テープはきれいに書いてあり、それを行うにはほんの数秒しかかかりませんでした。しかし、古いテープドライブを搭載したマシン上のテープから材料を取り出さなければなりませんでした。それで、それは一度に512バイトの素材を読んで、リールは前方に揺れて1ブロックを読んだ後、1​​/2インチだけ戻ってきて、次のブロックに進むために前方を読んだ後、そして、これを行うことができました。512バイトのブロックを読み取るには、1秒間にかなりの時間がかかっていたため、合計時間は恐ろしいものでした。私の飛行は出発する予定だったので...そのデータを渡す必要があった。 （それは十分に長い前で、遠く離れたところでは、飛行機への最後の変更はあまりオプションでもなかった）。長い話を短く切るために、それは読んだが、もし私が（デフォルトの512の代わりに5120バイトなど）、私ははるかに速く、飛行機を紛失する危険性がはるかに低くなりました（しかし、私は実際に飛行機に乗りました。ラッシュアワーでパリを渡ってタクシーに乗っているにもかかわらず）。

最新のテープドライブでは、バッファリングを行い、テープドライブをストリーミングするための十分なメモリがドライブに残っていました。以前はQICテープを流すために256KBのブロックサイズを使用していました。私は最近、テープドライブをあまり使っていませんでした。見てみましょう。この千年紀ではなく、数年前からあまり見られません。 CDやDVDが（電子ダウンロードが使用されなかったときの）選択したソフトウェア配布メカニズムとなって以来、確かにそうではありません。

しかし、ブロックサイズは本当に昔は問題でした。また、ddがそれに対応しています。 obs（出力ブロック）とは別にibs（入力ブロックサイズ）を指定することで、たとえば4 KBブロックで書き込まれたテープドライブから、16 KBブロックなどで書きたいテープドライブにデータを転送することもできますサイズ）。役に立った！

また、countのパラメータは（入力）ブロックサイズの観点からのものです。 1 MBのゼロをコピーするには、 'dd bs=1024 count=1024 if=/dev/zero of=/my/file/of/zeroes'と言うと便利でした。または1 M​​Bのファイルをコピーします。

ddの重要性は大幅に減少します。それは10年以上前にテープドライブで作業していた誰にとっても、兵器の不可欠な部分でした。