ファイルシステム
各種デバイスはデバイスファイルを介してアクセス。ストレージデバイスほとんどの場合はファイルシステムを介してアクセスする ディスク上の位置、空き領域の考慮、書き込み後に読み出すための位置とサイズとどんなデータが配置されているか、ユーザーが管理しなくともストレージデバイスの管理領域に保存されている
データとメタデータ
メタデータとは…ファイルシステム上に存在する付加情報
ファイルの名前、ストレージデバイス上の位置・サイズ、ファイル種類、時刻、権限、ディレクトリ情報など
ファイルへのアクセスはPOSIXによって定められた関数がある
ファイル操作:create(),unlink(),open(),close(),read(),write(),mmap()
ディレクトリ操作:mkdir(),rmdir(),chdir(),opendir(),closedir(),readdir()
これらによりファイルシステムの違いがあってもシステム上のファイル作成は可能になっている
2. カーネルのVFS(仮想ファイルシステム)という処理が動作し個々のファイルシステムの処理を呼ぶ
3. ファイルシステムの処理がデバイスドライバを呼ぶ
mmap()関数を呼び出しファイルの内容をメモリに読み出しその領域を仮想アドレス空間にマップする
メモリマップされたファイルはメモリと同じ方法でアクセス
容量制限(クォータ)
ユーザクォータ: /home 以下が一般ユーザの容量だけでいっぱいにならないようにする。ext4, XFS で使える
ディレクトリクォータ: ディレクトリに容量制限。ext4, XFS で使える
サブボリュームクォータ: サブボリュームという単位ごと容量制限。Brtfs で使える
整合性保持
ストレージへの読み書き中にシステムの電源が落ちるなど
ファイルbarをfoo配下に移動するようなディレクトリ移動 ⇢ fooからbarへのリンクを張る ⇢ rootからbarへのリンクを削除、といったように一連の不可分でアトミックな処理になっている
途中で電源が落ちるなどするとリンクがどちらにもある状態
ファイルシステム内にジャーナル領域というメタデータ領域を用意
アトミックな処理一覧をジャーナル領域へ書き出す、この一覧をジャーナルログ
ジャーナル領域の内容で実際にファイルシステムの内容を更新
一部不整合があっても次回起動時にログを元に更新する
更新後のファイルのデータを別の場所に書き込みリンクを張り替える
とはいえバックアップ。各ファイルシステムにはバックアップ用コマンドが用意されている
ext4 -> fsck, XFS -> xfs_repair, Btrfs -> btrfs check
fcsk はおすすめしないとのこと(整合性回復時にリンクが間違っている可能性がある
スナップショット
Btrfs が提供する機能:データのフルコピーではなくメタデータの作成
RAID の構成を組んで一方が破損されてもバックアップを残すことができる
Btrfs は破損の検知・修復も可能
全データチェックサムを持つ、データの読み出しでチェックサムエラー検出
読みだしたデータを捨ててI/Oエラーを通知、破棄したまま運用しRAID構成の残ったデータがあれば復旧させる
その他のファイルシステム
メモリベースの tmpfs、ストレージデバイスアクセスがないので高速 https://scrapbox.io/files/635fcabedbb9a8001d695f38.png
free コマンドの shared フィールが tmpfs によって使用されているメモリの量
sudo mount -t tmpfs tmpfs /mnt -osize=1G
1Gのtmpfsを作って /mnt にマウントする
https://scrapbox.io/files/635fcc681cbab3001dfd7bde.png
データアクセスが発生してからメモリが増えている
ネットワークファイルシステム
リモートホスト上にあるデータにファイルシステムのインタフェースでアクセスする(NFSやCIFS) 複数マシンのストレージデバイスを束ねて大きなファイルシステムとするCephFSというファイルシステムもある 通常 /proc 以下にマウントされ、プロセスの情報を格納している
/proc/<pid>/maps メモリマップ、**/cmdline コマンドライン引数、**/stat プロセスの状態
/cpuinfo, /diskstat, /meminfo, /sys/ディレクトリ以下のファイル
man 5 proc 参照
カーネルに関する情報、通常 /sys/ 以下にマウントされる
配下には block, bus, class, dev...など
man 5 sysfs 参照