何千もの小さなファイルをコピーすると、巨大な動画ファイルを1本移動するより遅く感じる理由
多くの人は、データのコピーをとても単純な作業だと考えています。片方のウィンドウからもう片方のウィンドウへファイルをドラッグし、進捗バーが画面上でゆっくり進むのを見て、最終的にファイルがコピー先のデバイスに表示される。外から見ると、複製用ハードウェアもまったく同じことをしているように見えます。ただし、より速く、より多くのUSBポートを使っているだけ、という印象です。
しかし内部では、この2つの方法はかなり違う動きをしています。
その違いは、複雑なフォルダ構造、ソフトウェア配布用データ、エンジニアリング系のアーカイブ、写真カタログ、Webサイトのバックアップ、あるいは何千、何万もの小さなファイルを含むデータを扱うときに、特に目立ちます。
これは、ストレージ性能について多くの人が混乱する理由でもあります。USBメモリが毎秒200MBの速度をうたっているとします。20GBの大きな動画ファイルをコピーすると、転送はとても速く感じます。ところがその後、80,000個の小さなファイルを含む2GBのソフトウェアプロジェクトを移動すると、急にコンピュータがひどく遅く感じられることがあります。
同じUSBドライブ。同じUSBポート。総データ量は少ない。
では、何が変わったのでしょうか。
答えはオーバーヘッドです。
ファイルコピーは、実は長いやり取りの連続
多くの人がファイルコピーを考えるとき、コンピュータが単にデータをある場所から別の場所へ移動しているだけだと想像します。ところが実際には、ドラッグ＆ドロップのコピー処理では、OSとストレージデバイスの間で非常に多くのやり取りが発生しています。
OSは各ファイルを一つずつ確認しなければなりません。ファイル名を確認し、フォルダを作成し、タイムスタンプを書き込み、アロケーションテーブルを更新し、メタデータを処理し、空き容量を確認し、書き込みセッションを開き、書き込みセッションを閉じ、各トランザクションが正しく完了したことを確認します。
1つの大きなファイルであれば、このオーバーヘッドは比較的小さく済みます。
しかし100,000個の小さなファイルになると、このオーバーヘッドは非常に大きくなります。
ある時点で、システムは実際に有用なデータを移動することよりも、コピー処理を管理することに多くの時間を使うようになります。
これが、ほとんどのユーザーには見えていない部分です。
クリップの問題
これをイメージする一番簡単な方法は、クリップで考えることです。
50ポンド分の物を、ある部屋から別の部屋へ移動しなければならないと想像してください。
1つの方法は、クリップが詰まった密閉された箱を運ぶことです。
もう1つの方法は、クリップを1個ずつ手で運ぶことです。
技術的には、総重量は同じです。
しかし片方の方法は、取り扱いの手間が作業全体を支配してしまうため、あまりにも非効率です。
小さなファイルは、ストレージシステムの中でこれと同じ問題を引き起こします。小さなファイル一つひとつが、それぞれ独立した小さなトランザクションになります。OSは、長く途切れないデータの流れを維持する代わりに、個々の部品を整理し、カタログ化し、検証し、管理するために、何度も立ち止まることになります。
だからこそ、20GBの動画ファイル1本のほうが、数千個の小さな画像、スクリプト、アイコン、キャッシュファイル、インストーラー、HTMLアセット、設定ドキュメントを含む2GBのフォルダよりも、速く転送されることがあるのです。
問題は、必ずしもデータ量ではありません。
問題は、取り扱う回数の多さです。
なぜバイナリ複製は動き方が違うのか
バイナリ複製は、この処理をまったく別の視点から見ています。
ファイルやフォルダに注目するのではなく、バイナリ複製の処理では、ストレージデバイスそのものの生の構造に注目することがよくあります。「このフォルダの中にどんなファイルがあるのか？」と聞く代わりに、システムは「このセクタにはどんなデータがあるのか？」と聞いているようなものです。
これは小さな違いに聞こえるかもしれませんが、作業の流れを根本的に変えます。
従来のファイルコピーは、OSを通して見えているファイルとフォルダだけを転送します。通常、ブートセクタ、パーティションテーブル、隠れたファイルシステム構造、デバイスのレイアウト情報といった低レベルのストレージ情報はコピーされません。
そのため、単にファイルをUSBメモリへドラッグしただけでは、通常、別のデバイスの本当の意味での起動可能なクローンにはなりません。ファイル自体は存在していても、ブートコードや、その下にあるストレージ構造が欠けていることが多いのです。
バイナリコピーやIMG展開は、ストレージ構造そのものを再現するため、挙動が異なります。複製方法によっては、パーティションテーブル、ブートセクタ、ファイルシステム構造、隠し領域、元メディアの正確なレイアウトまでコピーすることがあります。
環境をファイルごとに作り直すのではなく、複製処理はデバイスをより直接的な形で再現します。
そのため、転送中にOSが行う管理作業の量は大きく減ります。
IMGファイルやデバイスコピーが速く感じられる理由
これが、IMG展開やデバイスレベルの複製が、驚くほど速く一貫して感じられる理由の一つです。
システムは、何千もの小さなファイルシステム操作を処理するために絶えず立ち止まるわけではありません。その代わりに、整理された大きなバイナリデータのブロックを、よりシーケンシャルな処理として移動します。
シーケンシャルな処理は、細かく断片化されたランダム書き込みよりも、ストレージデバイスにとって通常はるかに効率的です。
これは、ソフトウェア配布、起動環境、Linux展開、組み込みシステム、キオスク端末、製造ワークフローなど、表面上は見えないところに膨大な数の小さな補助ファイルが存在する環境で、特に目立ちます。
通常のドラッグ＆ドロップコピーでは、OSがそれらの部品を一つずつ処理する必要があります。バイナリ複製では、そのオーバーヘッドの多くを回避できます。
その結果、より滑らかで、予測しやすく、多くの場合かなり速く感じられます。
同じような低レベルのUSB動作については、USB CD-ROMエミュレーションの仕組みに関する記事でも扱っています。そこでは、コントローラレベルの動作が、通常のファイルベースのワークフローとは大きく異なることが分かります。
USBの速度表記が誤解を招きやすい理由
消費者は、ストレージ速度を単純な1つの数字として考えるように教えられがちです。
しかし実際の性能は、作業内容の種類に大きく左右されます。
大きなシーケンシャルファイルは、ストレージシステムにとって扱いやすいものです。デバイスが長く途切れない書き込み処理を維持できるからです。一方で、小さく断片化されたファイルは、頻繁なストップ＆ゴーの動きを生み出します。
ドライブは、もはや空いた高速道路を全力で走っているわけではありません。
20メートルごとに一時停止標識がある市街地の交通を走っているようなものです。
この違いは非常に大きいものです。
そして、複製用ハードウェアやイメージングシステムが、通常のデスクトップコピー操作とは異なる動きをする理由もここにあります。データを移動する根本的な方法が、同じではないのです。
これは、USBデバイスがBOTやUASPを使う仕組みのような、低レベルのストレージ構造が見えているファイルと同じくらい重要になる製造ワークフローでは、さらに重要になります。
全体像
どちらの方法も、自動的に「優れている」というわけではありません。2つのアプローチは、解決している問題が違うからです。
従来のファイルコピーは柔軟です。個別のファイルを更新したり、特定のフォルダだけを置き換えたり、OS内で自然に作業したりできます。
バイナリ複製は、正確な再現とワークフローの効率性により重点を置いています。一貫性が重要で、大量の構造化されたデータを多くのデバイスへ確実に複製する必要がある場合に強みを発揮します。
ほとんどの人は、この違いについて考えることがありません。現代のOSは、その複雑さをシンプルな進捗バーの裏に隠しているからです。
しかし、その小さな緑色のバーの下では、ストレージシステムが実際にどのように動いているかに大きな違いがあります。
そして一度オーバーヘッドの存在を理解すると、巨大な動画ファイル1本を移動するのは軽く感じられるのに、何千ものファイルが詰まった小さなソフトウェアディレクトリのコピーが、高価なコンピュータさえ重く感じさせる理由が、急に納得できるようになります。
