はじめに：ファイルサーバ運用でハマったところから
自宅でLinuxのファイルサーバを運用していると、「あれ？ストレージっていつマウントされてるんだっけ」「そもそもマウントされてないと何ができないんだっけ？」みたいな疑問がちょこちょこ出てきます。
今回は、実際にトラブルっぽい挙動をきっかけに、マウント・パーティション・ファイルシステム・LVMあたりをまとめて調べ直した記録です。
自動マウントって何がやってるの？
最初の疑問はここでした。
USBストレージを挿したとき、勝手に使えることもあれば、何も起きないこともある。この違いは何なのか、という話です。
調べてみると、Linuxでは次のように分かれているらしいです。
- ストレージを「認識する」のはカーネルの仕事
- マウントするかどうかは、ユーザー空間側の仕組み
デスクトップLinuxだと、GUI環境が勝手にマウントしてくれます。一方、サーバ用途だと、fstab や systemd の設定がない限り、自動ではほとんどの場合マウントされません
つまり「Linuxが勝手にマウントしている」というより、「そういう設定や仕組みが載っているだけ」という理解が近そうです。
マウントされてないストレージは使えないの？
Linuxではストレージはマウントされてなくても/dev/sda/のような形で見えます。
結論から言うと、
- ファイルとしては使えない
- でも、生デバイスとしては読めてしまう
という状態らしいです。
ファイルとしてのアクセス
マウントされていないと、
- /srv/data/file.txt
- /mnt/usb/xxx
のようなパスが存在しないので、普通のファイル操作はできません。
生デバイスとしてのアクセス
一方で、/dev/sdb や /dev/sdb1 に対しては、dd などで直接読み書きができます。
ただしこれは、
- ファイルシステムを無視
- セクタ単位で殴る
- ミスると即破壊
というかなり危険な操作なので、実運用では「使える」とは言わない領域だと思ってよさそうです。
ファイルシステムってどのレイヤ？
ここで一度、頭の中を整理する必要がありました。
ストレージ周りは、ざっくり次の層になっています。
- 物理ストレージ（HDD / SSD）
- ブロックデバイス（/dev/sda など）
- パーティション（区画）
- ファイルシステム（ext4 など）
- マウント（ディレクトリに接続）
ファイルシステムは「ストレージに意味を与える層」で、ここで初めて「ファイル」や「ディレクトリ」という概念が生まれる、という理解になりました。
倉庫のたとえで考えると分かりやすかった
調べているとき、かなりしっくり来たのが倉庫のたとえです。
- 物理ストレージ：だだっ広い倉庫の床
- 生アクセス：床に直接物を置く
- ファイルシステム：棚・番号・台帳
- マウント：倉庫の出入口につなぐ
床に直接物は置けるけど、棚も番号もなければ、整理も効率も安全性もない。ファイルシステムなしのアクセスは、まさにそれに近い状態だと感じました。
ファイルシステムは、倉庫を効率的に使うための整理システムと言えそうです。
パーティションとフォーマットの違い
ここも混同しやすかったポイントです。
パーティションとは
- ストレージを論理的に区切るだけ
- 境界情報を書いているだけ
- ファイルの概念はない
倉庫で言うと、床に白線を引いて区画を分けただけ、という感じです。
A社の倉庫、B社の倉庫の縄張り的な感じですね。
フォーマットとは
- その区画にファイルシステムを作る
- 棚や管理ルールを設置する
- ここで初めて「使える」
実際に倉庫を運用するためのルールや整理方法を決める感じですね。
フォーマットとパーティションの順番
基本は
- パーティションを作る
- フォーマットする
- マウントする
この順番が前提です。
一応、先にディスク全体をフォーマットしてからパーティションを切ることも技術的には可能らしいですが、パーティションを作った時点でファイルシステムの管理情報が壊れてしまうこともあるので、あまり推奨されないようです。
ボリュームって結局なに？
「ボリューム」という言葉も、文脈によって意味が変わるので混乱しがちです。結構「ボリュームが…」という文章出てきますが、ボリュームが正確に何を指しているのかちょっとあやふやでした。
調べた限りでは、
- OSから見て
- ひとまとまりのストレージとして扱える単位
くらいの、かなり曖昧な言葉っぽいです。
パーティションを指すこともあれば、LVMの論理ボリュームを指すこともあります。
基本的には「ストレージとして認識できる塊」のことでOKそうです。
LVMって何をしている仕組み？
ファイルサーバーの運用をしていると、将来的な拡張に関して考えるべき時が来ます。それに関係してくるのがLVMです。
LVMはファイルシステムではなく、その下のレイヤにあります。
役割としては、
- ストレージ容量をプールする
- 後から分割・拡張しやすくする
というものです。
構成はよく
- PV（素材）
- VG（容量プール）
- LV（実際に使うボリューム）
と説明されます。
LVMは空き容量をやりくりする技術
自分なりの理解では、LVMは
- 使っている容量
- まだ割り当てていない容量
を明確に分けて管理するための仕組みです。
なので、VG内に空き（Free PE）がなければ、LVMでも新しい領域は作れません。物理的な容量制限からは逃げられない、という点はパーティションと同じです。
ディスク追加＝同じボリュームにできる？
LVMの強みとして、
- 物理的に別のディスクを
- 同じ論理ボリュームの一部として
扱える点があります。これはファイルサーバーの容量追加に効果的ですよね。
ただし、これは容量管理の話であって、冗長化ではありません。1本壊れたら全体が壊れる可能性が高いので、RAIDとは別物、という点は要注意です。
既存の非LVM環境はどうする？
自分のファイルサーバは、LVMを使っていません。正直ファイルサーバーを建てるときその知識が無かったためです。
この状態から後付けでLVMに移行できるか調べてみたところ、
- 技術的には可能
- 実務的には「データ退避→作り直し」になる
という結論でした。
無停止・低リスクでの後付け変換は現実的ではなく、
- 今の構成はそのまま使う
- 次に追加するディスクからLVMを使う
という折衷案が一番現実的そうだと感じました。
データを逃がしつつ、空き容量を確保しつつLVM化して、ボリュームを繋げていくといったイメージです。
おわりに
今回調べてみて、
- マウント
- パーティション
- ファイルシステム
- LVM
は、それぞれ役割がはっきり分かれているんだな、というのが一番の収穫でした。
全部まとめて「ストレージ周り」と呼びがちですが、レイヤを意識すると、トラブル時の切り分けもしやすくなりそうです。
コメント