Linuxカーネルの構造、tarファイルの構造の説明が一通り終わりましたので、これらの知識を総動員して、tarファイルシステム(tarfs)をどうやって作っていくのかを考えていきましょう。
最初に説明しましたが、tarファイルシステムをLinuxに追加するというのは、VFSに対して、サブクラスを追加するようなものであり、オリジナルのファイルシステムの固有の処理を実装するだけで済みます。
このため、tarファイルシステムとしては、VFSからの要求に対して、必要な処理を実行し、結果を返すだけで済みます。では、必要な処理とは何か? というと、「tarファイルをパース(解析)して、tarファイル内に存在するinode情報やユーザーデータを検索し、それらのデータを返すこと」です。
例として、先ほど説明したtarファイルをマウントして、ls testDirと実行した場合の処理の流れを簡単に見てみましょう。
これらの処理の流れのイメージを図7に示します。
それでは、次に、tarファイルのパース方法について考えてみましょう。以下に3つの案を考えてみましたので、どれがよいかを検討していきましょう(表4)。
案 | 内容 | ||
---|---|---|---|
1 | オンデマンドパース方式 | VFSからの要求に対して、tarファイル全体を読み込み・パースして、結果を返す | |
2 | 一括キャッシュ方式 | マウント時にtarファイル全体をパースし、全データをメモリ上に展開し、キャッシュしておく。そして、VFSからの要求に対して、このキャッシュを使って結果を返す | |
3 | メタデータ構築方式 | マウント時にtarファイル全体をパースし、メタデータを構築する。そして、VFSからの要求に対して、このメタデータを使って結果を返す | |
表4 tarファイルのパース案 |
これら3つの案をメモリ使用量、I/O量の観点から比較した結果を以下にまとめてみました(表5)。
案 | メモリ量 | I/O量 | メリット | デメリット | |
---|---|---|---|---|---|
1 | 小 | 大 | (1)tarファイルのサイズが小さければ、特に問題はない | tarファイルのサイズが大きいと以下のデメリットが顕著に表れる (1)tarファイル全体の検索が頻繁に発生するので、I/O量が無視できないほど大きくなる可能性がある |
|
2 | 大 | 中 | (1)tarファイルのサイズが小さければ、特に問題はない | tarファイルのサイズが大きいと以下のデメリットが顕著に表れる (1)マウント時に、tarファイル全体をパースするため、マウント時間が長くなる可能性がある (2)メモリ量が無視できないほど大きくなる可能性がある (3)搭載メモリ量が少ないと、スラッシングが発生する可能性がある |
|
3 | 小 | 小 | (1)必要なメタデータ領域しかアクセスしないため、案1、2に比べて、メモリ量、I/O量は低く抑えることができる (2)メタデータを構築するので、2回目以降のマウント時間はtarファイルサイズに依存しない |
(1)メタデータを構築する必要がある (2)メタデータをどこに配置するかが悩みどころ |
|
表5 tarファイルのパース案の比較検討結果 |
今回の設計では、以下に示す理由により、案3のメタデータ構築方針を採用することにします。
ただ、メタデータをどこに配置するのか? という問題が残っています。これについては、少し大胆なやり方ですが、図8のようにtarファイルの終端からメタデータを書き出すという案を考えてみました。
読者の皆さんは、「そんなことをすると、tarファイルを今後使えなくなってしまう!」と思われますよね? ですが、tarコマンドの展開処理では、終端(ゼロクリア領域)以降は参照しないように実装されており、大きな問題にはならないのです。実際に、tarファイルの終端以降にデータを書き込んだ後に、tarファイルを展開してみましたが、正常にデータを参照できました。
ただし、このtarファイルに新たにファイルを追加する場合は、メタデータが壊れてしまうので注意が必要です。この問題を回避するためには、tarfsをアンマウントするときに、メタデータ領域を削除すればよいのですが、そうするとマウントのたびに、メタデータの構築が必要となってしまいます。
いろいろ悩んだ揚げ句、このtarfsの使用用途を、
「バックアップ用のtarファイル(今後、新たにファイル追加が発生しない)内のファイルを参照するためのファイルシステム」
と限定して、メタデータは削除しないことにしました(注12)。
これで、tarfsの作り方の概要は一通り説明し終わりました。次回は、tarファイルのメタデータ構築とマウントの処理について解説します。お楽しみに!(次回に続く)
Copyright © ITmedia, Inc. All Rights Reserved.