第4章　ファイルシステムのマウントと整合性維持

LPIC-1 104.2 / 104.3 相当

作成したファイルシステムをディレクトリツリーに組み込む（マウントする）方法と、容量・整合性を確認する方法を扱います。

mount / umount

$ sudo mount /dev/sdb1 /mnt/data     # /dev/sdb1 を /mnt/data にマウント
$ mount                              # 現在マウント中の一覧を表示
/dev/sda2 on / type ext4 (rw,relatime)
tmpfs on /run type tmpfs (rw,nosuid,size=1622560k)
/dev/sdb1 on /mnt/data type ext4 (rw,relatime)
...（この後もマウント中の項目が続く）
$ sudo umount /mnt/data              # アンマウント

この行のこの値に注目： mountとumount自体は成功時に何も出力しませんが、その状態を確認したいときはmount（引数なし）を実行すると、末尾の/mnt/dataの行から目的のマウントが反映されているかを確認できます。各行のtype以降にある(rw,relatime)のような括弧内は、実際に有効になっているマウントオプションです。

この方法での mount は再起動すると消えてしまう一時的な設定です。再起動後も自動でマウントさせたい場合は /etc/fstab に登録します。

/etc/fstab の書式

UUID=1234-5678  /mnt/data  ext4  defaults  0  2

デバイス名（/dev/sdb1など）は接続順によって変わることがあるため、変わらない識別子であるUUIDを使うのが安全です。UUIDは blkid コマンドで確認できます。

$ blkid /dev/sdb1
/dev/sdb1: UUID="1234-5678" TYPE="ext4"

容量とファイルシステムの状態を確認する

代表的なマウントオプション

これらは mount -o オプション名 のように指定するか、/etc/fstabの4列目にカンマ区切りで並べます。外部から接続するUSBメモリなどには noexec,nosuid を付けて、不正な実行ファイルが動くリスクを減らすといった運用がよく行われます。

fstabの動作確認とtmpfs

/etc/fstabを編集した後、実際に再起動しなくても内容が正しいかを確認する方法があります。

$ sudo mount -a       # fstabの未マウントエントリをすべてマウント（構文エラーがあればここで検出できる）
（構文・デバイスともに問題がなければ何も表示されない）
$ findmnt /mnt/data   # 特定のマウントポイントの詳細情報を確認
TARGET     SOURCE      FSTYPE OPTIONS
/mnt/data  /dev/sdb1   ext4   rw,relatime

この行のこの値に注目： mount -aは正常時は無出力ですが、fstabに構文ミスがあるとmount: /mnt/data: mount point does not existのようなエラーがここで表示されるため、再起動前の事前チェックとして重要です。findmntはその1エントリだけを表形式で表示するため、fstabで指定したオプション（この例ではrw,relatime）が実際に適用されているかを確認できます。

また、tmpfsはディスクではなくメモリ上に作られる一時的なファイルシステムで、/tmpや/runによく使われます。再起動するとすべての内容が消える点に注意してください。

tmpfs  /tmp  tmpfs  defaults,noexec,nosuid,size=1G  0  0

マウント中のファイルシステムをアンマウントできないとき

「device is busy」のようなエラーでumountが失敗することがあります。これは、そのファイルシステム上のどこかのファイルやディレクトリを、まだ何らかのプロセスが使用中であることが原因です。

$ sudo umount /mnt/data
umount: /mnt/data: target is busy.
$ sudo fuser -vm /mnt/data      # そのマウントポイントを使用中のプロセスを表示
                     USER        PID ACCESS COMMAND
/mnt/data:           user       2048 ..c.. bash
$ sudo lsof +D /mnt/data        # 同様に、開いているファイルの一覧から使用中プロセスを特定
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME
bash     2048 user  cwd    DIR   8,17     4096       2 /mnt/data

この行のこの値に注目： fuserのACCESS列にあるcは「そのディレクトリをカレントディレクトリとして使用中」を意味し、PID 2048のbashがそこにいることが分かります。lsofのFD列のcwdも同じ意味で、この場合はどちらもPID 2048のシェルが原因なので、そのシェルでcdして/mnt/dataから抜けるか、そのプロセスを終了させればアンマウントできるようになります。

mount --bind によるバインドマウント

あるディレクトリを、別のディレクトリの中にも見せかけて重ねてマウントする「バインドマウント」という使い方もあります。ディスクを分けずに、同じ内容を複数の場所から参照させたい場合などに使われます。

$ sudo mount --bind /var/www /srv/www_mirror   # /var/www の中身が /srv/www_mirror からも見える

マウント状態を確認する2つの視点

現在のマウント状態は複数の場所から確認できますが、それぞれ性質が異なります。

dfの出力例と主なオプション

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        50G   32G   16G  67% /
/dev/sda1       512M  120M  392M  24% /boot
tmpfs           2.0G     0  2.0G   0% /dev/shm

この現象の原因調査には lsof | grep deleted を使うのが定番です。「(deleted)」という表記が付いたファイルが見つかれば、それがディスク容量を握ったまま解放されていないファイルの正体です。該当プロセスを安全に再起動できない場合でも、ログ出力先を切り替えてから元のファイルディスクリプタを閉じさせる（logrotateのcopytruncate設定など）という回避策が使われることもあります。ディスク容量に関するトラブルシューティングの全体的な流れは、トラブルシューティングの記事でも扱っています。

マウントできない・遅いときの切り分け

マウント操作自体が失敗する場合、エラーメッセージを手がかりに原因を絞り込みます。「wrong fs type」はファイルシステムの種類指定の誤り、「bad option」はオプション指定のミス、「already mounted」はすでに別の場所にマウント済みであることを示しています。一方、マウント自体は成功するのに読み書きが極端に遅い場合は、ネットワークファイルシステム（NFS等）の接続品質や、ディスク自体の物理的な劣化を疑う必要があります（ディスクの健全性確認は上級編で扱うsmartctlが役立ちます）。エラーメッセージの文言を注意深く読む習慣が、原因特定の時間を大きく左右します。