P338
V6
- 直接 4KB
- 間接 896KB
- 二重間接 32MB
FreeBSD
三重間接参照が出来るようになった(最大4TB)
拡張属性ブロック
10bとか小さすぎるファイルはそもそもストレージ領域にデータが入っていなくて拡張属性ブロックに直接データが存在する。
inodeの枯渇→動的inode
P345
inodeが大量に存在すると枯渇してファイルやディレクトリが作られなくなり、ディスク容量に余裕はあるのに使えなくなってしまう。→ダンプをとってファイルシステムの復元
inode構造体
2つ存在する
- ディスク上のinode
- メモリ上のinode
inode番号をハッシュとして管理する
- V6は16ビット
- FreeBSDは32ビット
ファイルの名前検索においてはキャッシュを利用して行われる
シンボリックリンク vs ハードリンク
- シンボリックリンク /usr/sue/bar は /usr/joe/foo のリンクで名前だけもっており、ファイルの実体はそれぞれ違う
- ハードリンク /usr/joe/foo と /usr/sue/bar はファイルの同じ実体を見ている
クォータ
あるユーザーに対して書き込めるディスクサイズの制限を加える。これをしないとすべてのユーザーが無制限にディスクを使えてしまうため。
ハードリミットとソフトリミットがある。
- ソフトリミット 警告
- ハードリミット 停止
書き込みのたびにクォータを見るのは非効率なので、メモリ上に帳簿のようなものがあり、そこからクォータを見る。これで短期間でクォータを見ることができる。
ファイルロック
ファイル内の任意の範囲について適用できる。
デッドロック対策。
(P360-P368とそのあたりがなんか抜けてた)
ファイルシステムのスナップショット
ある時点でのファイルシステムのイメージを固定したもの
- バックアップ
- ダンプ
- 失われたブロックやinodeを回収する
ファイルシステムは常に変わるから、ある時点の記録を残しておいて、残したものを後から参照できるようにする(履歴ファイル)
ダンプするとクソ遅くなる
ファイルシステムのスナップショットの作成 P381
実装自体は単純。
- スナップショットファイルの作成(差分のようなものを用意しており、新旧どちらのファイルシステムも参照できる)
- 一時的に今現在のファイルの書き込みをブロックする
- ファイル操作関連をチェックし、スナップショットが作成されるまで中断する
- 中断された処理はスナップショットの作成が完了したときに実行される
スナップショットを何回もとることも考えて、まるっとバックアップせずに差分だけを残す
仮スナップショット
- 中断準備中(ms)
- 完全中断中(ms)
- 同期(1s)
- 仮スナップショットを更新(1s)
- 再開
ファイルシステムが大きくなればなるほど時間がかかるようなものにしないために↑のような手順となっている。
シリンダグループごとにスナップショットをとってるけど、3の段階で進捗状況をビットマップで管理してる。
P394にさらなる詳細が書かれている。
シリンダグループって何
ファイルを分割して管理するグループのこと。
スナップショットの管理
- 普通のファイルと同様にスナップショットファイルも削除されればinodeは0となる
- 再起動後も有効
- 複数のスナップショットを作成することは可能であるが、古いスナップショットを削除してもそのブロックはフリーリストにかえらずにあたらしいスナップショットに移行する
- あるブロックがフリーされると、他のスナップショットが必要であるかどうかを見る。
ファイルシステムが大規模になるとどうなるの
- メタデータはメモリにおかれているのが理想であるが、メモリに置けるデータは小規模であるので大規模ファイルシステムに対応できない
シリンダグループ間でのデータ移動は予期せぬことが起こりやすい。故にキャッシュのスラッシングを防ぐ必要がある(スラッシングとは 【 thrashing 】 - 意味/解説/説明/定義 ： IT用語辞典)
デッドロックの解決方法→単一のロックを使う + ルックアサイドテーブル
