【3/18〜】Amazon、VMwareが語る『クラウドの未来』 スラッシュドット    はてなブックマーク  Yahoo!ブックマークに登録  印刷
   
コラム

NTFSではフラグメントは発生しにくい?
―― NTFS基礎のキソ ――

デジタルアドバンテージ
2000/10/21

 Windows NTの発表とともに新しいNTFSファイル・システムが紹介されたとき、マイクロソフトは「NTFSはFATと違ってフラグメントが起こりにくい」と公言していた。すでに述べているとおり、実際にはNTFSにおいてもフラグメントは日常的に発生する。それでは、何を根拠にこのような発言がなされたのだろうか? この理由は、NTFSで採用されたアイデアによるものと思われる。複雑なNTFSファイル・システムのすべてを紹介するのは別の機会に譲るとして、NTFSの大きな特徴の1つであるこのアイデアについてご紹介しよう。

その秘密はMFT(Master File Table)にあり

 ファイル・システムでは、広大なディスク領域をクラスタと呼ばれる固定領域に区切り、このクラスタを単位として割り当てることで、ディスク中にファイルを保存できるようにしている。ファイルのデータが、物理的にどのクラスタにどのような順番で記録されているかを管理するのがファイル・システムの役割であり、ファイルの読み書き要求に応じて、それを物理的なクラスタへのアクセスに変換する。

 MS-DOSやWindows 9xが採用するFATファイル・システムも、こうした基本的な管理方式は変わらない。そもそもFATファイル・システムという名前の由来は、ファイルとそれを構成するクラスタの対応関係などを記録した管理テーブルがFAT(File Allocation Table)という名称だったことによる。ファイル名やファイルの属性(読み出しのみ属性、隠しファイル属性など)、タイムスタンプなどはディレクトリ・エントリと呼ばれる特殊な領域に保存されるようになっていた。

 これに対しNTFSでは、ディスク中に含まれるすべてのファイルやディレクトリ(フォルダ)ごとに固定長の管理レコードを作成し、これを集中的に管理することで、ファイル・システムの柔軟性と機能性、信頼性を向上させようとしている。この管理レコード群はMFT(Master File Table)と呼ばれる。MFTの概要を図示すると次のようになる。

NTFSの心臓部、MFTの構成
MFT(Master File Table)は、ファイルやディレクトリごとに1つ(ないし複数)が対応する固定サイズ(通常は1Kbytes)のレコードからなる。このレコードの内部には、ファイル名やタイムスタンプ(日付)に加え、ファイルの属性が記録される。ユニークなのは、ファイルのデータ自体も属性の一部として捉え、サイズの小さなもの(他の属性にもよるが、通常は750bytes程度かそれ以下)については、MFT中のレコードに直接データを記録してしまうことだ(図の上側のレコード)。一方、MFTレコード内に収まりきらないサイズのファイルについては、MFT外部のクラスタにこれを書き込み、そのクラスタへのインデックスをMFTレコードに記録しておく。

 このようにMFTは、固定長のレコードからなるテーブルで、NTFSボリューム中に存在するファイルやディレクトリごとに1つ(ないし1つ以上)のエントリが対応する。レコード・サイズは最小で1Kbytes、最大で4Kbytesだが、通常は1Kbytesである。新しいファイルやディレクトリ(フォルダ)が作成されると、MFT内のレコードが1つ割り当てられる。

 MFTには、ファイル名やファイルのタイムスタンプ(作成日時/更新日時/アクセス日時)、アクセス権などの基本情報に加え、ファイルのデータ自身(ファイル本体)も属性の一部として捉える。これがNTFSの大きな特徴の1つだ。つまり他の属性データのサイズにもよるが、通常は約750bytes程度までの小さなファイルなら、MFTレコード内に記録されてしまうのだ(図の上側にある「小さなファイルのレコード」)。この場合、ファイル名などに関する情報と、データ自体を同じ場所から読み出すことが可能なので、ファイル・アクセスは極めて高速になる。

 一方、MFTレコードに収まりきらないようなファイルについては、MFTファイル以外の領域に一連の新しいクラスタが割り当てられ、そこへのインデックスのみがデータ属性内に記録される(図の下側にある「大きなファイルのレコード」)。ファイルに必要なサイズの連続したクラスタを1度に確保できない場合には、このクラスタへのインデックスは複数になる。これはまさにフラグメントしているファイルである。図には示していないが、1つのレコードにすべての属性が収まりきらない場合には、1つのファイルに対して複数のMFTレコードを使用することもある。なおNTFSでは、ディレクトリ(フォルダ)もファイルの一種として取り扱われるようになっており、わずかなファイルしか含んでいないディレクトリの情報は、MFTレコード内だけで完結できる。MFTレコードだけでは収まりきらないほどファイルが増えてきたら、MFT外部のクラスタを使う点も通常のファイルと同じである。

 ファイルのすべてが物理的に連続したクラスタに書き込まれている場合には、MFTレコード内のインデックスも1つですむが、フラグメントによってデータがとびとびになる場合は、それらの先頭クラスタへのインデックスがMFTレコードに記録される(ファイルがフラグメントしているというのは、このような状態を指す)。

予想外にたくさんある「小さな」ファイル

 このようにNTFSでは、小さなファイルやディレクトリに関しては、MFTレコードだけですべての情報を記録できる。つまり、小さなファイルによってクラスタが虫食い状態にならないということだ。

 問題は、750bytes未満などという小さなファイルがどれほどあるかであるが、実際にWindows 2000の検索機能を使って、手元のコンピュータでそれらのファイルをざっと検索してみたところ、ディレクトリやアプリケーションのショートカット、インターネット・ショートカット([お気に入り]メニューなどに登録される)、クッキーなどなど、実に数多くのファイルが存在している。FATではフラグメントの要因ともなっていたこれらのファイルも、MFTレコードのメカニズムによって、NTFSではフラグメントの要因から除外されている。特にこの種の小さなファイルは、一時ファイルなどとして頻繁に作成・削除されることを考えれば、かなりの影響があるだろう。

 もちろん、MFTレコードに収まらないサイズの大きなファイルについては、NTFSであってもフラグメントは起こる。しかし従来のFATに比較してフラグメントが発生しにくいとされた根拠は、この新しいMFTのメカニズムを指していたものと考えられる。

MFT自体もフラグメントを起こす可能性がある

 NTFSファイル・システムにおいては、MFTが重要な役割を果たすことがお分かりいただけただろう。ボリュームをNTFSでフォーマットすると、MFT用として、あらかじめボリューム全体の12.5%の領域が確保されるようになっている。

 しかし1つのボリュームに数多くのファイルが存在する場合や、激しいファイルのフラグメントに起因するクラスタのインデックスによってMFTレコードが不足した場合には、32レコード単位で自動的にMFTが拡張される仕様になっている。しかし前出のページング・ファイル同様、この場合には、MFTが激しくフラグメントを起こす可能性が高い。MFTはNTFSボリューム全体を管理する重要なデータであり、これがフラグメントを起こすと、ファイル入出力性能に大きな影響を及ぼすだろう。

Inside Microsoft Windows 2000 Third Edition
Windows 2000カーネルの内部を詳細に解説したユニークな解説書。Windows 2000の内部機構を知りたい技術者には必携の書。
Book Reviewを読む

 ページング・ファイルとは異なり、このMFTの自動拡張を抑制するようなオプションな存在しない。ただし後述するDiskeeperには、このMFTのフラグメントを防止するという機能(Frag Guard機能と呼ばれる)が追加されている。

 なお、紙数の都合から、ここではNTFSのメカニズムを詳しく述べられなかったが、NTFSの内部構造を詳しく知りたければ、『Inside Windows 2000 Third Edition』(Microsoft Press発行)が参考になるだろう(囲み記事参照)。


 INDEX
  [検証] ディスク・デフラグメント完全マスター
    1.ディスク・フラグメントの基礎知識(1)
     コラム:NTFSではフラグメントは発生しにくい?
    2.ディスク・フラグメントの基礎知識(2)
    3.Windows 2000標準のデフラグ・ツールを使う(1)
    4.Windows 2000標準のデフラグ・ツールを使う(2)
    5.フル機能版のDiskeeper 5.0を使う(1)
    6.フル機能版のDiskeeper 5.0を使う(2)
    7.検証:フラグメントはシステム・パフォーマンスにどれだけ影響を及ぼすのか?(1)
    8.検証:フラグメントはシステム・パフォーマンスにどれだけ影響を及ぼすのか?(2)
 
 検証

ホワイトペーパーTechTargetジャパン

Windows Server Insider フォーラム 新着記事

@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

RSSフィード

スキルアップ/キャリアアップ(JOB@IT)

- PR -
- PR -

お勧め求人情報

キャリアアップ 〜JOB@IT
@IT Special -PR-
  TomcatやJBossなどAPサーバ環境に関する
情報を集約! “業務”用APサーバ大百科

New!
  一気に解説! 最新のクラスタストレージ
「RAIDを超えたストレージ基準」……など

New!
  クラウド的ユーザー体験の変化は脅威か?
仮想化技術を使いこなす運用管理術を紹介

New!

  上司や部下、部署内メンバーとの情報共有
を“ガラッ”と変えるコラボツールとは?

New!
  おばかアプリ選手権、第4弾開催中!!
ムダにカッコよくてくだらない作品求ム!

  社内ファイルサーバを“クラウド”に統合
VPN直結「クラウド型ストレージ」を紹介

  Twitterのアカウントはなぜ突破された?
メールによる新手の攻撃手法とその対策

  もう仮想化のお試しフェイズは終わりだ!
Hyper-V 2.0が基幹システムも仮想化

  美人!? まあまあ? 気になる いやし系!!
PV急増で「美人時計」がとった手段とは?

  クライアント企業から求められる人材
⇒IT技術と経営戦略を併せ持つ「戦略家」

  .NET編集長が実践する「技術情報検索術」
サンプル・コードを簡単に探す“技”は?

  業務効率と情報セキュリティ対策を両立!
手間なく確実に機密情報を守る方法とは?

  進化を続ける富士通ストレージETERNUS DX
製品開発者の自信を裏付けるものとは何か

  運用管理の課題を“2つの観点”から分析
ユーザー満足度の高い「仮想環境」とは?

  【CTC事例】約30の基幹システムを統合!
膨大なバッジジョブを制御した方法は?

  仮想化すればコストは削減できるか?
仮想化に必要な「3つの視点」を解説する

  その数、なんと400台以上! グループ内
サーバの「統合管理」によるメリットは?