Embed Size (px)
Citation preview
ファイルシステムの構造
1. 補助記憶装置（ディスク）の構造
2. ボリュームとファイルの管理
3. ディレクトリとネーミング関数
4. 領域割当（外部断片化と内部断片化）
5. 領域管理（ UNIXとMS-DOS（Windows）での実際）
ファイルをデータ領域に割り当てる場合，連続領域への割当が最も簡単な方法
データを編集する場合，ファイルサイズが動的に伸縮することになる．
その結果，予め割り当てた領域に対して，（小さくなれば隙間が生じ，大きくなれば本体全体が移動するので）空き領域が発生する．
領域割当（外部断片化と内部断片化～その１）
外部断片化とは
縮小
伸張のため移動
このようにディスクのデータ領域のあちこちに断片化した空き領域が発生
領域全体の使用効率が低下
「外部断片化（external fragmentation）」と呼ぶ．
空き領域
領域割当（外部断片化と内部断片化～その２）
外部断片化とは
外部断片化
連続した領域を割り当てる方式
外部断片化により，分散した空き領域が発生．
これらを１つの大きな空き領域にまとめれば，再利用も容易．
その操作は「詰め直し（compaction）」と呼び，多大な所要時間を要する（メモリ内での大量データ移動のため） ．
領域割当（外部断片化と内部断片化～その３）
内部断片化とは
ブロックなど固定サイズの領域を単位として，割り当てる方式が有効（ブロック割当方式）．
連続割当方式と比較し，ファイルの伸縮に対応でき，外部断片化を回避可能．
◆連続割当（１つのファイルに関するデータ領域が集約） ＶＳ ブロック割当方式（１つのファイルに対するデータ領域がディスク全体に散在）
アクセス効率の低下（シリンダをまたいだ場合，毎回のアクセスにシーク時間まで含まれることになる）．
領域割当（外部断片化と内部断片化～その４）
内部断片化とは
一般には，いくつかのブロックをクラスタ（cluster）としてまとめ，散逸を回避する．
しかし，この方法で領域を割り当てても，最後のブロック内には基本的に無駄な空き領域が発生する可能性あり．
「内部断片化（internal fragmentation）」と呼ぶ．
一般に，内部断片化は避けにくく，ブロックサイズを調整し（初期設定時に），システムの最適化を図ることが必要．
領域割当（外部断片化と内部断片化～その５）
内部断片化とは
領域割当（外部断片化と内部断片化～その６）
内部断片化とは
ブロック内に未使用部分：内部断片化の発生
各ファイルの領域割当後のイメージ
ファイル
ブロック割当で各ファイルの領域割当を行う：確かに，外部断片化は発生しないが・・・
ファイルシステムの構造
1. 補助記憶装置（ディスク）の構造
2. ボリュームとファイルの管理
3. ディレクトリとネーミング関数
4. 領域割当（外部断片化と内部断片化）
5. 領域管理（ UNIXとMS-DOS（Windows）での実際）
領域管理（その１）
領域割当とその管理（領域管理）の基本的考え方
領域割当で最も簡単な手法は連続領域割当である．しかし，以下のような問題点も発生
ファイルの大きさを事前に宣言 事前確定は困難
領域の外部断片化の発生 ファイルを編集することで（領域割当と解放を繰返すことで）ディスク領域などに空き領域が発生
連続領域割当の使用効率を改善 詰め直し（Compaction）が必要 ブロック割当の妥当性
内部断片化の発生は不可避 どれだけ効率化するかが問題
領域管理（その２）
（主流である）ブロック割当方式での領域管理方式
使用（中の）領域管理と空き（未使用の）領域管理
使用領域の管理：使用中である領域の効率的管理
リスト方式 リストであれば頭からサーチ
索引（インデックス）方式
空き領域の管理：未使用である領域の効率的管理
リスト方式 リストであれば頭からサーチ
ビットマップ方式
使用領域の管理（その１）：リスト方式
特徴：
ファイルを構成するブロックを先頭から順にリストして保持
各ブロックには次のブロックへのポインタが存在
ディレクトリには先頭ブロックへのポインタが登録
途中のポインタが破壊されると修復が困難
順アクセスには効果的だが，直接アクセスには不向き
２
０ １
５
３２
４
７
６
１０
５ ７
８ ９ １１１０
１２ １３ １４ １５
・・ ディレクトリに格納
データブロック
ファイル名
使用領域の管理（その２）：索引方式
特徴：
索引が存在．各ブロックへのポインタを表形式で保持（これを索引indexと呼称）
ファイル事に索引が生成，ディレクトリに索引（or索引へのポインタ）が格納
直接アクセスも容易（リスト方式の改善）．但し，索引のための領域が別途必要
０ １ ２ ３
４ ５ ６ ７
８ ９ １０ １１
１２ １３ １４ １５
データブロック
２
５
７
１０
索引
ファイル名 ・・ ディレクトリに格納
空き領域の管理（その１）：リスト方式
特徴：
空き領域を構成するブロック群を順にリストして保持
各未使用ブロックには次のブロックへのポインタが存在
１つの空きブロックを得るのに１回のディスクアクセスが必要
０
１ ３ ４
０ １ ２ ３
６ ８
４ ５ ６ ７
９ １１
８ ９ １０ １１
データブロック
空き領域の先頭
但し，空き領域管理には複雑なアクセス手順は不要で，必要なブロックだけリストを手繰って確保すればリストの更新は容易・・ディスクアクセスを低減するためキャッシュなどを活用
空き領域の管理（その２）：ビットマップ方式
０ １ ３２
４ ６５ ７
８ ９ １１１０
データブロック
１ １ ０ １
１ ０ １ ０
１ １ ０ １
特徴：
ディスク中のブロックを１ビットに対応させ，対応するブロックが使用中なら「０」に，未使用なら「１」にセット
ビットマップ用のデータを１つの領域に確保
Bitmap
ＵＮＩＸの領域管理（その１）：索引方式
■ＵＮＩＸでは，ブロックを単位に領域割当
■ファイル領域は索引で保持
■巨大なファイルの総てのブロックを一元的な索引で登録するのは非常に大きな索引を必要とするので効率が悪い
■間接ブロック（単一，二重，三重）を活用してブロックを管理 ・・・ 巨大なファイル容量を実現（使用頻度は多くないが）
i-node
直接
単一間接二重間接
三重間接
ＵＮＩＸの領域管理（その２）：索引方式
i-node
ブロック容量×12
×1024
×1024
×1024 ×1024
×1024 ×1024
×1024 ×1024×1024理論上のファイル容量は・・・
ＭＳ－ＤＯＳの領域管理（その１）：ＦＡＴ方式
■ＭＳ－ＤＯＳでは，ディスクをクラスタに分割し，クラスタ単位に領域割当
■ディスク領域の管理はＦＡＴを利用．ＦＡＴのエントリは各クラスタ（のインデクッス）に対応
■ディスク領域のクラスタには順に番号が付与．ＦＡＴでその番号をインデックスとする表を管理
■１つのファイルに使用されるクラスタをポインタで繋ぎ，保持．使用中のクラスタに対応するＦＡＴ上のインデックスには，次のクラスタ番号が記載
■ＦＡＴが欠損すればファイルへのアクセスは不能
ＭＳ－ＤＯＳの領域管理（その２）：ＦＡＴ方式
Ａ １
Ｂ ４３
Ｆｒｅｅ
５
６
ＥＮＤ
７
９
Ｆｒｅｅ
ＥＮＤ
Ｆｒｅｅ
ディレクトリ
ファイル 位置
ＦＡＴ
１ ３ ５
４ ６ ７ ９
Ａ：
Ｂ：
ファイルごとにリスト化されたブロック群
ＦＡＴが欠損すればファイルを構成するブロック間の接続情報が失われ，ＯＳなどがファイルにアクセスできない状況に陥る
Windowsの領域管理（その１）：ＮＴＦＳ方式
■NTFS（NT File System）：旧FATを進化させたもの。XP以降のWindowsに使用でき、現在の主流。
■2TB以上のドライブサイズを管理可能（実装256TB）
■最大16TBのファイルサイズを管理可能、最大ファイル名長は255文字まで（Unicode）
■ファイルの変更履歴などの情報を保存するジャーナリング機能。圧縮、暗号化機能などの実装あり。FATより高機能、高堅牢性
出典： https://ja.wikipedia.org/wiki/NT_File_System
Windowsの領域管理（その２）：ＮＴＦＳ方式
■堅牢性向上：突然の電力供給停止などの障害が発生時、トランザクションログから、実行した処理をロールバックでき、ファイルシステム不整合を防止するジャーナリングファイルシステムをサポート。
■耐障害性：ハードディスク内不良セクタの動的認識（以降そのセクタを含むクラスタに対するアクセスは別のクラスタに自動代替）。但し、冗長性確保が前提なので、確保がないと不良セクタ上のデータ回復は不可。
■暗号化：Windows 2000以降のNTFSは、Encrypting
File Systemをサポートし、NTFSボリューム上のファイル
とフォルダの透過的な暗号化をサポート。但し、暗号化されたファイルやフォルダは常に圧縮されているため、自分自身の証明書を失うとシステム管理者を含めて誰も永久にアクセス不可。
代表的なファイルシステム
■ファイルシステム（FAT32、FAT16、NTFS、exFAT、HFS、HFS+、APFS）の違いについて
■既にFATやNTFSについては前述。後半はMacOS
上のファイルシステム：HFS、APFSなども個別には特徴を理解して使用するべき。以下のURLにも比較掲載されているので参考になる。
■MacOSがUnix/MACH系なので、それとの親和性が良いが当然Windowsとの互換性も図られている。
https://www.buffalo.jp/support/faq/detail/1079.html
