読み方:えぬてぃーえふえす
《NT file system》米国マイクロソフト社のオペレーティングシステムで採用されているファイルシステム。Windows NT、Windows XPなどに用いられている。
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2026/01/25 00:42 UTC 版)
|
|
この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。 (2025年9月)
|
| NTFS | |
|---|---|
| 開発者 | マイクロソフト |
| 正式名 | NT File System |
| 導入 | 1993年7月 (Microsoft Windows NT 3.1) |
| パーティション識別子 | 0x07 (MBR)EBD0A0A2-B9E5-4433- (GPT) |
| 構造 | |
| ディレクトリ | B+木 |
| 領域管理 | ビットマップ/Extents |
| 不良ブロック | ビットマップ/Extents |
| 限度 | |
| 最大ファイル サイズ | (実装上) 16 TiB(Windows 7、Windows Server 2008 R2まで)、 256 TiB - 64 KiB(Windows 8、Windows Server 2012以降[1]) 8 PiB - 2 MiB (Windows 10 バージョン1709、Windows Server 2019以降[2]) (理論上)16 EiB |
| 最大ファイル数 | 232-1 (4,294,967,295) |
| 最大ファイル名長 | 255文字(UTF-16) |
| 最大ボリューム サイズ | (実装上) 256 TiB - 64 KiB(Windows 10 バージョン1703、Windows Server 2016まで) 8 PiB - 2 MiB(Windows 10 バージョン1709、Windows Server 2019以降)[2] (理論上)264-1 クラスタ |
| ファイル名の文字 | |
| 特徴 | |
| タイムスタンプ | アクセス、 作成、 修正、 POSIX変更 |
| 日付範囲 | 1601年1月1日 - 60056年5月28日 |
| 日付分解能 | 100ナノ秒 |
| フォーク | 可能 |
| 属性 | 読み取りのみ (R)、 隠し (H)、 システム (S)、 アーカイブ (A)、インデックスサービス非対象 (I)、オフライン (O)、圧縮 (C)、暗号化 (E)、テンポラリ (T)、スクラビング非対象 (X) |
| パーミッション | ACL |
| 透過的圧縮 | ファイル毎。LZ77。XPRESS(Windows 10のみ)[3]。LZX(Windows 10のみ)[3]。 |
| 透過的暗号化 | ファイル毎。 DES-X: (Windows 2000) トリプルDES: (Windows XP) AES:(Windows XP SP1、Windows Server 2003以降) |
| 重複排除 | ファイル単位(2000から2012 R2までのWindows Server)、 可変サイズブロック単位(2012以降のWindows Server) |
| 対応OS | Windows NT系 |
NTFS(英: NT File System)とは、マイクロソフトが開発したWindows NT系専用の標準ファイルシステムである。ファイル圧縮や暗号化、トランザクション、ファイルごとのアクセス許可などデータ保全に資する機能が複数実装されている。クラスターサイズに影響されるが、最大8 PBのボリュームサイズがサポートされている[4]。
NTFS 1.2とNTFS 3.xとの間には互換性が無く、Windows NT 4.0上からNTFS 3.xにアクセスするには、Service Pack 4以上を適用する必要がある。また、Windows 2000以降で、自身が使用しているバージョンよりも前のバージョンのNTFSにアクセスすると、その時点で自身が使用しているバージョンに変換する。
PC/AT互換機のパーティションテーブルIDが、HPFSと同じであるため、登場当初はディスク ユーティリティが誤動作することがあった。
Microsoftによると、NTFSの後継ファイルシステムではないと否定されているが、サーバ向けOSであるWindows Server 2012においてNTFSの欠点を解消したReFSを導入している。ホームコンピュータ向けエディションのWindows HomeやWindows Proでは今後もNTFSが使われていく予定であるが、これらのエディションにおいても23H2以降において、開発者向けにReFSが利用可能であるため、後継ファイルシステムとして検討されている可能性が高いとされている[5]。
Windows NT 3.51からサポートされたファイル圧縮をNTFSもサポートしている。LZNT1アルゴリズム(LZ77の変種)を使用したファイル単位での透過的な圧縮をサポートし、ディスクの空き領域を増加させることができる。ただし、4 KiBを超えるアロケーション ユニット サイズでは圧縮機能を利用できない。
加えて、スパースファイルもサポートする。ファイルの一部が0で埋められている場合、クラスタ単位で0で埋められている領域をスキップし、ディスク容量を節約する。これはデータベースのハッシュテーブル ファイルや仮想マシンの仮想ハードディスク ファイルなど大部分が0で埋められているファイルで効率よく働く。
NTFSには小さなファイルをファイルのメタデータと一緒にMFT内に収める機能がある。これはアロケーション ユニットを割り当てない事による若干の容量面のメリットとユーザーデータの読み取りにメタデータとは別のI/Oを必要としない速度面のメリットがある。
ファイル数は少ないが巨大なファイルを格納したいと思うなら、最大2048 KiB のアロケーション ユニット サイズを選択できる。これにより、断片化の問題、管理領域とデータ領域の比率など、ファイルシステム性能を左右する問題を解決する。
NTFS圧縮やスパースファイルの使用、極度の断片化によるエクステント リストを使い切ってしまう状況に対応するためのオプションが有り、これの使用によって規定では1 KiBのファイルレコードを4 KiBまで増加させることができる[10]。副次的な効果としてMFT内に収められるユーザーデータも増加する。
なお、2010年時点でのNTFSの実装では、クラスタ数は232-1までとなっている。このため、16 TiBを超えるボリュームは、4 KiBを超えるアロケーション ユニット サイズを指定しなければならない。サポートされているアロケーション ユニット サイズは2048 KiB (Windows 10 バージョン1703、Windows Server 2016までは最大64 KiB)までである。したがって、NTFSボリュームは8 PiBまでの制限がある。また、OSのバージョンと容量によってはシャドウ コピー機能に制限がある。
仮想DOSマシン上で動作するソフトウェアに対して、ファイル システム上で一意なパス名であることを保証した8.3形式ファイル名を保存することができる。この機能は任意に有効・無効を設定することができるので、NTFSのファイルシステム最適化の代表的なものとされるが、非推奨とされていた。Windows 7では有効・無効をボリューム単位で設定できるようになりシステムボリュームでは有効、データボリュームでは無効といった運用が可能となった(フォーマット時の規定値は有効)。Windows 8ではパフォーマンス上の理由により8.3形式のファイル名は非推奨となり[11]フォーマット時の規定値がシステムボリュームを除き無効となった。
原則としてファイル名の大文字小文字は区別されるが、サブシステムがこの機能の有効無効を選択している。Win32サブシステムではファイル名の大文字小文字は区別されず、ファイル名の大文字小文字が異なるファイルを上書きした場合は、最後に使われたファイル名のファイルが保存される。POSIX・Interixサブシステム・Windows Subsystem for Linuxではファイル名の大文字小文字は区別され、ファイル名の大文字小文字が異なるファイルは上書きされず別のファイルとして保存される。
さらに高度な応用としてファイル システム フィルターを備え、ファイルシステム機能やファイルシステム上の名前空間を任意のソフトウェアでオーバーライド(継承)できる。この機能をもとに圧縮機能・暗号化機能・ファイル変更ジャーナル・スナップショット機能・クォータ機能をサブシステムを含むユーザー プロセスからは何ら変更の無いアクセスで利用できる透過的な実装が行われたほか、サードパーティによるファイル システムに対するフォレンジック監査の実装などに活用されている。
Windows NT系には、ファイルシステムの論理エラーまたは物理エラーの確認およびファイルシステムの修復コマンドとして、「chkdsk」コマンドが用意されている[12]。実際にファイルシステムの修復を行うには、「chkdsk 〈対象ボリューム〉 /f」を、不良クラスタの修復を試みるには、「chkdsk 〈対象ボリューム〉 /r」を実行する。
ファイル数の増加に伴う chkdsk の実行時間の増加に対しWindows 8では従来のメタデータの走査とエラーの修復の両方をボリュームをオフラインにして行う方式からメタデータの走査とエラーの記録をオンラインで行いエラーの修復のみをオフラインで行う方式に変えた為、ボリュームのダウンタイムはデータ量には依存しなくなった[13]。
また、NTFSはMFTの「$BadClus」ファイルに不良クラスタの情報を記録しているため、不良クラスタを含むパーティションをパーティションコピーツールなどで丸ごと他のハードディスクにコピーすると、「$BadClus」ファイルもそのままコピーされてしまい、新しいハードディスクには不良クラスタが存在しないにもかかわらず、chkdskでは不良クラスタが存在しているように見えることがある。これを修復してリセットするには、「chkdsk 〈対象ボリューム〉 /b」を実行する(ただし、Windows VistaまたはWindows Server 2008以降のみ)。
ファイルシステム上の不良クラスタとS.M.A.R.T.におけるバッドセクタは別物である。
なお、chkdskによるNTFSの修復により、ディスク エラーの状況が悪化する場合があるため、修復の前に重要なファイルはバックアップしておくことが推奨される。また、chkntfsコマンドを使用することで、Windows起動時に自動的にchkdskを実行したり、自動実行をキャンセルしたりすることができる[14]。
これはNTFSの欠点ではなく、ファイルシステムという仕組みの性質であるが、データの削除やデータサイズの増減を許容するファイルシステムでは、それら操作時の必要に応じてコンパクションを行わない限り、いずれかの段階でフラグメンテーションが発生する。NTFSはFAT32と比較しフラグメンテーションしにくい。その根拠としてMFT機能が挙げられている[15]。フラグメンテーションの量はアロケーション ユニット サイズに反比例し、最も小さなアロケーション ユニット サイズの512バイトで最も顕著になる[16]。
FATよりは軽度とされたそのフラグメンテーションの実体は、Diskeeperのレポート機能などによって一般に知られるようになった。Windows 2000からNTFS対応のデフラグ ツールがWindowsに標準搭載された。
基本的にはファイル名はUCS-2で格納される。ここでファイル名を非UNICODE文字種とUNICODEで参照した場合、名前の不一致が発生する。名前の不一致はコードページに依存し、名前空間の一貫性を損なってしまう。原則として厳密に名前空間を取り扱うのであれば、UNICODEでアクセスすべきで、ロケール依存コードページによってアクセスすべきではない。慣例的にコードページ依存文字を使うftpなどのプロトコルの取り扱いは注意を必要とする。
NTFSは従来のDOSファイルシステムにはない、ファイル最終アクセス時刻を記録する。その為ファイルを読みだしただけでもディスクへの書き込みが生じる。このリード・モディファイ・ライトの特性が悪い方向に働くケースはいくつかある。一つは小さなたくさんのファイルへのアクセスでファイルシステムの性能を、ひどいときには25%まで低下させてしまう[要出典]。もう一つはフラッシュメモリを使ったデバイスにアクセスした時に頻繁にページのフラッシュを発生させ、やはりファイルシステムの性能を低下させてしまう。Vista以降最終アクセス時刻は既定で更新されない。[17]
NTFSは元々、Windows NT系におけるサーバ用途を目的として開発されたファイルシステムであり、DOSから使われてきたFATと互換性を持たない。そのため、クライアント向けのOSであるWindows 9x系からアクセスすることはできない。
Windowsでは標準となったNTFSだが、マイクロソフトの戦略やセキュリティにより、その仕様が一般には公開されていない。有志によって不完全ながらもNTFSにアクセスするための手段が用意されているが、他のOSからの読み書きするにはリスクが生じる。マイクロソフトではファイルの受け渡しに使われるフラッシュドライブ向けに最適化されたexFATの仕様を公開している。