第7章 ファイルシステムの保守と自動マウント
LPIC-2 203.2〜203.3 相当
中級の第4章では手動・fstabによる恒久マウントを扱いました。ここではファイルシステムを「作った後」の保守作業（Btrfsの運用・XFSの運用・ext系の深掘り）、「アクセスされたときだけ自動的にマウントする」仕組み、そしてディスクの健全性監視を扱います。多数のNFS共有を抱える環境や、ディスク故障を未然に検知したい運用では、いずれも実務で日常的に使う知識です。
Btrfsの設計思想
Btrfsは、従来のext系やXFSとは異なる設計思想を持つ、比較的新しいファイルシステムです。3つの特徴が中核にあります。
| 特徴 | 内容 |
|---|---|
| CoW（Copy on Write） | 既存のデータブロックを直接上書きせず、変更内容を新しい場所に書き込んでからメタデータの指し先を切り替える方式。これにより、スナップショットをほぼ瞬時に作成でき、書き込み途中のクラッシュでも元のデータが破壊されにくい |
| チェックサムによる整合性検証 | データとメタデータの両方に対してチェックサムを保持し、読み出し時に自動的に検証する。サイレントデータ破損（ディスク側で気づかれずにビットが化ける現象）を検知できる |
| ボリュームマネージャ機能の内蔵 | 複数の物理デバイスをまたいだRAID構成（後述のmkfs.btrfsでの複数デバイス指定）を、LVMを別途使わなくてもBtrfs自身の機能として扱える |
これらの設計により、Btrfsは「ファイルシステム」と「ボリュームマネージャ」の境界を曖昧にし、LVM＋ext4のような複数層の組み合わせを、Btrfs単体である程度代替できるように作られています。
ファイルシステムの比較
| 項目 | ext4 | XFS | Btrfs | ZFS |
|---|---|---|---|---|
| CoW | 非対応 | 非対応 | 対応 | 対応 |
| スナップショット | 非対応（LVM層で代替） | 非対応（LVM層で代替） | 標準機能として対応 | 標準機能として対応 |
| 縮小（shrink） | 可能 | 不可（再作成が基本） | 可能（オンライン） | 可能 |
| RAID機能 | 非搭載（mdadm等に依存） | 非搭載（mdadm等に依存） | 搭載（0/1/10/5/6相当） | 搭載（RAID-Z） |
| 成熟度 | 非常に高い（枯れている） | 高い（大容量・高スループット実績豊富） | 中〜高（RAID5/6は実運用に注意が必要とされる） | 高い（LinuxではOpenZFSとして提供） |
| 推奨用途 | 汎用・安定性最優先の用途 | 大容量ファイル・高スループットが必要な用途 | スナップショット・整合性検証を重視する用途 | 大規模ストレージ・エンタープライズ用途 |
Btrfsの基本操作
$ sudo mkfs.btrfs -L mydata /dev/sdb
btrfs-progs v6.6.3
Label: mydata
UUID: 1a2b3c4d-5e6f-7890-abcd-ef1234567890
Node size: 16384
Filesystem size: 100.00GiB
Block group profiles:
Data: single 8.00MiB
Metadata: DUP 1.00GiB
$ sudo mkfs.btrfs -L mydata -d raid1 -m raid1 /dev/sdb /dev/sdc
btrfs-progs v6.6.3
Label: mydata
Filesystem size: 200.00GiB
Block group profiles:
Data: RAID1 1.00GiB
Metadata: RAID1 256.00MiB
# 複数デバイスを指定すると、そのままBtrfs自身のRAID機能でミラーリング等を構成できる
# -d はデータのプロファイル、-m はメタデータのプロファイルを指定（別々に指定可能）この行のこの値に注目： Block group profilesのData/Metadata行が、実際に選ばれたプロファイルです。複数デバイス指定時は既定でもMetadataがDUP（複製）になりますが、-d raid1を指定するとデータ自体もミラーリングされ、片方のデバイスが故障してもデータが失われません。
$ sudo btrfs filesystem show
Label: 'mydata' uuid: 1a2b3c4d-...
Total devices 2 FS bytes used 12.34GiB
devid 1 size 100.00GiB used 20.00GiB path /dev/sdb
devid 2 size 100.00GiB used 20.00GiB path /dev/sdc
$ sudo btrfs filesystem df /mnt
Data, RAID1: total=20.00GiB, used=12.30GiB
System, RAID1: total=32.00MiB, used=16.00KiB
Metadata, RAID1: total=1.00GiB, used=120.00MiB
$ sudo btrfs filesystem usage /mnt
# filesystem df より詳細に、デバイスごとの未割り当て領域まで含めて表示
Overall:
Device size: 200.00GiB
Used: 24.60GiB
Free (estimated): 174.70GiB (min: 174.70GiB)
Data,RAID1: Size:20.00GiB, Used:12.30GiB (61.50%)
/dev/sdb 20.00GiB
/dev/sdc 20.00GiBこの行のこの値に注目： Free (estimated)がRAIDプロファイルを考慮した実際の空き容量の見積もりです。単純なdfのFree列とは異なり、RAID1構成では書き込むデータ量の2倍を消費することを織り込んだ値になっています。
dfコマンドが表示する使用量と、btrfs filesystem df/usageが示す値はしばしば一致しません。BtrfsはRAIDプロファイルに応じてデータを複製・分散して格納するため（例：RAID1なら実容量の半分しか使えない）、また領域を「チャンク」単位で先に確保してから実際にデータを書き込むため、単純な「使用済みバイト数」だけでは実態を表しきれないのが理由です。正確な空き容量を把握したい場合は、dfではなくbtrfs filesystem usageを使うのが確実です。
$ sudo btrfs device add /dev/sdd /mnt # 稼働中のファイルシステムにデバイスを追加（正常時は無出力）
$ sudo btrfs device delete /dev/sdc /mnt # データを他デバイスへ再配置してから、デバイスを取り外す（完了まで時間がかかることがある）
$ sudo btrfs balance start /mnt # データ配置をプロファイル・デバイス構成に合わせて均等化する
Done, had to relocate 4 out of 20 chunks
$ sudo btrfs filesystem resize +10G /mnt # オンラインで10GB拡張
Resize '/mnt' of '+10G'
$ sudo btrfs filesystem resize -5G /mnt # オンラインで5GB縮小
Resize '/mnt' of '-5G'この行のこの値に注目： balance完了時のhad to relocate N out of M chunksが、実際に再配置されたチャンク数です。resizeは成功するとResize '/mnt' of '...'とだけ表示され、実際の変更後サイズはdf -h /mntで別途確認します。
device add／device deleteはいずれもオンライン（マウントしたまま）で実行でき、balanceはデータやメタデータをデバイス間・チャンク間で再配置し、デバイス構成の変更後や断片化した空き領域を整理したい場合に使います。filesystem resizeは+／-で相対指定、あるいは絶対サイズを指定でき、拡張・縮小の両方をオンラインで行える点がXFSとの大きな違いです。
サブボリューム
Btrfsでは、1つの物理パーティションの中に、独立してマウント・スナップショット可能な「サブボリューム」を複数作成できます。
$ sudo btrfs subvolume create /mnt/@home
Create subvolume '/mnt/@home'
$ sudo btrfs subvolume list /mnt
ID 256 gen 10 top level 5 path @
ID 257 gen 12 top level 5 path @home
$ sudo btrfs subvolume delete /mnt/@home
Delete subvolume (no-commit): '/mnt/@home'この行のこの値に注目： subvolume listのID列がサブボリュームIDで、subvol=の代わりにsubvolid=マウントオプションを使う場合はこの番号を指定します。deleteの(no-commit)は、削除処理自体は即座にトランザクションキューへ入るものの、ディスク上への実際の反映（コミット）はファイルシステム側のタイミングで行われることを示しています。
サブボリュームは、マウント時にsubvol=（パス指定）またはsubvolid=（ID指定）オプションで、どのサブボリュームをルートとしてマウントするかを指定できます。
/etc/fstab の例
UUID=1a2b3c4d-... / btrfs subvol=@,defaults 0 0
UUID=1a2b3c4d-... /home btrfs subvol=@home,defaults 0 0@をルート用、@homeをホームディレクトリ用のサブボリュームとして分離する命名は、Ubuntuの既定レイアウトなどで使われる慣習です。ルートとホームを別サブボリュームに分けておくと、後述のスナップショットもそれぞれ独立して取得・ロールバックでき、たとえば「システムだけを更新前の状態に戻すが、ユーザーのホームディレクトリは巻き戻さない」といった柔軟な運用が可能になります。
スナップショット
$ sudo btrfs subvolume snapshot /mnt/@ /mnt/@-snap-20260821
Create a snapshot of '/mnt/@' in '/mnt/@-snap-20260821'
# 書き込み可能なスナップショットを作成（CoWにより、変更差分だけが新たに容量を消費する）
$ sudo btrfs subvolume snapshot -r /mnt/@ /mnt/@-snap-ro-20260821
Create a readonly snapshot of '/mnt/@' in '/mnt/@-snap-ro-20260821'
# 読み取り専用スナップショット（-r）。バックアップの一貫した取得元や、送信元として使うことが多いこの行のこの値に注目： -rを付けた場合は出力にreadonlyという語が加わり、作成されたスナップショットが読み取り専用であることが明示されます。読み取り専用かどうかはbtrfs subvolume showでも後から確認できます。
スナップショットからのロールバック手順：
- 問題が起きたサブボリューム（例：
@）の名前を、調査用に一時的にリネームしておく（mvではなくbtrfs subvolumeのIDやパスを控えておく） - 復元したいスナップショット（
@-snap-20260821）を、書き込み可能な状態で本来の@という名前・パスに配置し直す（読み取り専用スナップショットの場合は、まず書き込み可能なスナップショットをそこから作り直す） - ブートローダー／fstabが参照するサブボリューム名・IDが正しく切り替わっているか確認してから再起動する
ここで確認すべきこと： ロールバック後は、意図したスナップショット時点の内容に戻っているか、他のサブボリューム（@homeなど）に予期しない影響が出ていないかを必ず確認します。
読み取り専用スナップショット同士の差分だけを転送するsend／receiveを使うと、効率的な増分バックアップを実現できます。
$ sudo btrfs send /mnt/@-snap-ro-20260821 | ssh backup-server "btrfs receive /backup/btrfs"
At subvol /mnt/@-snap-ro-20260821
At subvol @-snap-ro-20260821
# 初回はスナップショット全体を転送
$ sudo btrfs send -p /mnt/@-snap-ro-20260821 /mnt/@-snap-ro-20260822 | ssh backup-server "btrfs receive /backup/btrfs"
At subvol /mnt/@-snap-ro-20260822
At subvol @-snap-ro-20260822
# -p で基準となる前回のスナップショットを指定すると、その差分だけを送信できる（増分バックアップ）この行のこの値に注目： btrfs send側のAt subvol ...は送信元、btrfs receive側のAt subvol ...は受信先での書き込み進捗を示します。-pを付けた2回目の実行は、前回との差分ブロックだけを転送するため、全体を再送する場合よりも大幅に転送量が少なくなります。
scrub・btrfs-convert・圧縮
Btrfsのチェックサムを活かした整合性検証がscrubです。
$ sudo btrfs scrub start /mnt # チェックサムの検証（と、RAID構成であれば自動修復）をバックグラウンドで開始
scrub started on /mnt, fsid 1a2b3c4d-... (pid=8821)
$ sudo btrfs scrub status /mnt # 進捗・検出したエラー件数を確認
UUID: 1a2b3c4d-5e6f-7890-abcd-ef1234567890
Scrub started: Fri Aug 21 09:00:00 2026
Status: finished
Duration: 0:04:12
Total to scrub: 24.60GiB
Rate: 99.32MiB/s
Error summary: no errors foundこの行のこの値に注目： Error summaryがno errors foundであれば、全データのチェックサム検証で異常が見つからなかったことを意味します。ここにcsum errorsなどのカウントが表示された場合、RAID構成であれば自動修復されますが、単一デバイス構成では修復できずデータ破損として扱われます。
scrubは全データを読み出してチェックサムと突き合わせ、RAID1/RAID10などの冗長構成であれば、破損が見つかったブロックを正常な複製から自動的に修復します。定期的なscrubの実行（多くのディストリビューションでは週次のsystemdタイマーが用意されている）は、サイレントデータ破損を早期に検知する上で重要です。
既存のext4パーティションをBtrfsへ変換するbtrfs-convertも用意されています。
$ sudo btrfs-convert /dev/sdb1 # ext4からBtrfsへ変換
creating btrfs metadata.
creating ext2_saved subvolume.
conversion complete.
$ sudo btrfs-convert -r /dev/sdb1 # 変換を取り消し、ext4に戻す（元のext4イメージがsnapshotとして保持されている間のみ可能）
rollback complete.この行のこの値に注目： creating ext2_saved subvolumeという行が、元のext4イメージをロールバック用に保持している証拠です。rollback completeが表示されればロールバック成功ですが、ext2_savedを削除済みの場合はこの操作自体がエラーで失敗します。
変換直後は、元のext4イメージがext2_savedという名前のサブボリューム（スナップショット）として保持されており、これが存在する間は-rで元のext4に戻せます。ただし、このスナップショットを削除してしまうと、以後はロールバックできなくなります。
圧縮を有効にすると、ディスク容量の節約とI/O量の削減を両立できる場合があります。
マウントオプションでの圧縮指定
/dev/sdb1 /mnt btrfs compress=zstd:3,defaults 0 0compress=zstd:3は、zstdアルゴリズムを圧縮レベル3で使う指定です（数値が大きいほど圧縮率は上がりますがCPU負荷も増えます）。Btrfsは重複排除（同一内容のブロックを1つだけ実体として保持する機能）にも対応していますが、標準では有効化されておらず、専用ツール（duperemoveなど）によるオフラインでの重複排除が一般的な利用形態です。オンラインでの重複排除は処理負荷が大きいため、常時有効化するかどうかは用途に応じた検討が必要です。
ZFSの認識レベルの知識
ZFSはSun Microsystems（現Oracle）が開発した、ボリューム管理とファイルシステムを統合したシステムです。管理コマンドはzpool（プールと呼ばれる物理デバイスの集合の管理）とzfs（その上に作成するデータセット・ファイルシステムの管理）の2系統に分かれます。
$ sudo zpool create tank mirror /dev/sdb /dev/sdc # ミラー構成のプールtankを作成（正常時は無出力）
$ sudo zpool status # プールの健全性を確認
pool: tank
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
sdb ONLINE 0 0 0
sdc ONLINE 0 0 0
$ sudo zfs create tank/data # プール上にデータセットを作成（正常時は無出力）
$ sudo zfs snapshot tank/data@2026-08-21 # スナップショットを作成（正常時は無出力）この行のこの値に注目： zpool statusのstate: ONLINEとREAD/WRITE/CKSUM列がすべて0であれば正常です。これらのエラーカウントが増加している場合は、対応するディスクに物理的な問題が生じている可能性が高く、交換の検討が必要です。
ZFSはCDDLというライセンスで公開されており、GPLv2のLinuxカーネルとライセンス上の互換性に議論があるため、Linuxカーネルには標準で同梱されておらず、OpenZFSプロジェクトが提供する追加パッケージ（カーネルモジュール）として別途導入する必要があります。RAID相当の機能（RAID-Z）・スナップショット・重複排除・チェックサムによる自動的なデータ破損検知などを、LVM・mdadm・ファイルシステムそれぞれ別々に用意する代わりに1つの仕組みで提供する点が特徴です。LPIC-2の出題範囲では、ZFSについては深い操作知識までは求められず、「LVM+ext系/Btrfsの組み合わせとは異なる統合型のアプローチであり、ライセンスの都合上Linuxカーネルには同梱されていない」という位置づけを理解していれば十分です。
XFSの運用
| コマンド | 用途 |
|---|---|
xfs_info | マウント済みのXFSファイルシステムの詳細情報（ブロックサイズ、AGの数など）を表示 |
xfs_growfs | ファイルシステムを拡張する（縮小には対応していない） |
xfs_repair | 破損したXFSファイルシステムを修復する |
xfsdump / xfsrestore | XFS専用のバックアップ・リストアツール |
$ xfs_info /mnt/data
meta-data=/dev/sdc1 isize=512 agcount=4, agsize=6553600 blks
data = bsize=4096 blocks=26214400, imaxpct=25
naming =version 2 bsize=4096 ascii-ci=0, ftype=1
log =internal log bsize=4096 blocks=12800, version=2この行のこの値に注目：bsizeはブロックサイズ（既定4096バイト）、agcountはAG（Allocation Group、割り当てグループ）の数です。XFSは内部を複数のAGに分割して並列にI/O処理できるよう設計されており、agcountが多いほど（CPUコア数やディスク構成に見合っていれば）並列度を活かしやすくなります。
$ sudo xfs_growfs /mnt/data # マウントしたまま拡張できる（オンライン拡張）
meta-data=/dev/sdc1 isize=512 agcount=4, agsize=6553600 blks
data = bsize=4096 blocks=26214400, imaxpct=25
data blocks changed from 26214400 to 34603008この行のこの値に注目： 最終行のdata blocks changed from ... to ...が拡張結果です。拡張前後のブロック数が実際に増えていることを確認できます。agcount（AGの数）は既存のAGを維持したまま最後のAGだけが拡張される仕組みのため、拡張後もこの値自体は変わりません。
xfs_growfsは拡張専用で、縮小したい場合はバックアップを取ってファイルシステムを再作成するのが基本的な対処法になります。
$ sudo umount /dev/sdc1 # 正常時は無出力
$ sudo xfs_repair -n /dev/sdc1 # -n（no modify）で、実際には修復せず問題の有無だけを確認する
Phase 1 - find and verify superblock...
Phase 2 - using internal log
- scan filesystem freespace and inode maps...
Phase 3 - for each AG...
- agno = 0
- agno = 1
bad magic number 0x0 for inode 1052
would have corrected inode count
No modify flag set, skipping filesystem flush and exiting.
$ sudo xfs_repair /dev/sdc1 # 実際に修復を実行
Phase 1 - find and verify superblock...
...
Phase 6 - check inode connectivity...
Phase 7 - verify and correct link counts...
doneこの行のこの値に注目： -n実行時に問題が見つかるとwould have corrected ...のように「もし実行していたら何をするか」だけを表示し、最後のNo modify flag set, skipping...で実際には何も変更していないことが分かります。本番の-nなし実行では最後にdoneと表示されれば修復完了です。
xfs_repairはマウント中のファイルシステムに対しては実行できません（マウントされたまま実行しようとするとエラーで拒否されます）。必ず先にumountしてから実行する必要があります。まず-nで問題の有無を確認し、実際の修復が必要かどうかを判断してから、-nなしで再実行するのが安全な手順です。$ sudo xfsdump -l 0 -f /backup/data.dump0 /mnt/data
# レベル0（フルバックアップ）を実行
xfsdump: level 0 dump of server:/mnt/data
xfsdump: dump date: Fri Aug 21 09:00:00 2026
xfsdump: session id: 3f2a1b4c-...
xfsdump: session label: ""
xfsdump: ... dump complete: 12345 seconds elapsed
$ sudo xfsdump -l 1 -f /backup/data.dump1 /mnt/data
# レベル1（レベル0以降の変更分のみの増分バックアップ）
xfsdump: level 1 dump of server:/mnt/data
xfsdump: dump date: Sat Aug 22 09:00:00 2026
xfsdump: based on level 0 dump started Fri Aug 21 09:00:00 2026
xfsdump: ... dump complete: 320 seconds elapsedこの行のこの値に注目： based on level 0 dump started ...行が、この増分バックアップがどのフルバックアップを基準にしているかを示します。この情報は前述の/var/lib/xfsdump/inventoryから自動的に読み取られるため、手動で基準を指定する必要はありません。
この行のこの値に注目：xfsdumpのレベルは0〜9まで指定でき、レベル0が完全（フル）バックアップ、レベル1以降はそのレベルより小さい直近のダンプからの増分バックアップになります（バックアップの世代管理に近い考え方です）。xfsdumpは、どのファイルシステムをいつ・どのレベルでダンプしたかを記録する「インベントリ」を/var/lib/xfsdump/inventoryに保持しており、増分バックアップの基準を自動的に追跡します。
$ sudo xfsrestore -f /backup/data.dump0 /mnt/restored
xfsrestore: using online session inventory
xfsrestore: searching media for dump
-> 1 # 複数の候補がある場合、対話的にどのダンプを使うか選択を求められることがある
xfsrestore: restore completeext系の深掘り
tune2fs -lは、スーパーブロックに保存されている全情報を読み取り専用で一覧表示します。
$ sudo tune2fs -l /dev/sdb1
Filesystem volume name: mydata
Filesystem UUID: 1a2b3c4d-5e6f-...
Filesystem state: clean
Mount count: 12
Maximum mount count: 30
Check interval: 15552000 (6 months)
Reserved block count: 524288
Reserved GDT blocks: 256
Free blocks: 8388608
Free inodes: 524000この行のこの値に注目：Filesystem stateがcleanであれば前回正常にアンマウントされたことを示し、not cleanは不正な終了（電源断など）があった可能性を示します。Mount countとMaximum mount countは、後述の-cで設定した強制fsckの周期に対する現在の進捗です。
| オプション | 意味 |
|---|---|
-c | マウント回数がこの値に達すると強制的にfsckを実行する周期を設定 |
-i | 前回のfsckからの経過時間で強制fsckを行う間隔を設定（例：6mで6か月） |
-m | 一般ユーザーの書き込みから予約しておくブロックの割合（既定5%。root専用の緊急用領域） |
-L | ボリュームラベルを設定 |
-U | UUIDを設定・再生成する |
-O | 機能フラグ（feature flag）を追加・削除する（^を前置すると削除） |
$ sudo tune2fs -c 30 -i 6m /dev/sdb1 # 30回マウントごと、または6か月ごとのいずれか早い方で強制fsck
tune2fs 1.47.0 (5-Feb-2023)
Setting maximal mount count to 30
Setting interval between checks to 15552000 seconds
$ sudo tune2fs -m 1 /dev/sdb1 # 予約ブロック率を1%に変更（大容量ディスクで5%は過大なことが多い）
tune2fs 1.47.0 (5-Feb-2023)
Setting reserved blocks percentage to 1% (5242880 blocks)
$ sudo tune2fs -O ^has_journal /dev/sdb1 # ジャーナリング機能を無効化（^で機能フラグを削除、ext3相当からext2相当に近づく）
tune2fs 1.47.0 (5-Feb-2023)この行のこの値に注目： -c/-iや-mのように具体的な数値を変更する操作は、変更後の実際の値（この場合は秒数やブロック数に換算された値）が確認メッセージとして表示されます。-Oのような機能フラグの変更はメッセージが出ないことも多く、変更が反映されたかはtune2fs -lで再確認するのが確実です。
$ sudo dumpe2fs /dev/sdb1 | less
Group 0: (Blocks 0-32767)
Block bitmap at 259 (+259)
Inode bitmap at 275 (+275)
Inode table at 291-802 (+291)
22869 free blocks, 8181 free inodes, 2 directoriesdumpe2fsは-hを付けるとスーパーブロックの情報のみ（tune2fs -lとほぼ同じ内容）、付けない場合はブロックグループごとの詳細（各グループのビットマップ位置、空きブロック数・空きinode数など）まで表示します。
debugfsは、ファイルシステムの内部構造を対話的に調べる低レベルツールです。
$ sudo debugfs /dev/sdb1
debugfs: stat <12>
Inode: 12 Type: regular Mode: 0644 Flags: 0x80000
Links: 1 Blockcount: 8
...
debugfs: ls -d /lost+found
2 (12) . 2 (12) .. 11 (20) <11>deleted-file.txt
debugfs: quitstatサブコマンドは、指定したinode番号やパスの詳細情報（パーミッション、ブロック配置など）を表示します。ls -dは削除マーク済みだが未上書きのinode（<番号>の形式で表示される）も含めて一覧表示でき、誤って削除したファイルのinode番号を特定した上で、そのブロックの内容をdebugfsから手動で救出できる可能性があります（確実な復旧を保証するものではありません）。
fsckでは対応できない特殊なトラブル（誤って削除したファイルの復旧調査など）に使われる強力なツールですが、書き込みモードで誤ったコマンドを実行するとファイルシステムをさらに破壊するおそれがあります。原則として読み取り専用の調査目的で使い、書き込みが必要な操作を行う前には必ずバックアップを取ります。
autofs — オンデマンドの自動マウント
常時マウントしておく必要がない共有ストレージ（NFSなど）は、アクセスされた瞬間だけマウントし、一定時間使われなければ自動的にアンマウントする autofs が便利です。fstabに常時マウントの記述を大量に並べると、対象サーバーがダウンしているだけで起動そのものが遅延したりハングしたりするリスクがありますが、autofsであればアクセスが発生するまでマウントを試みないため、そうしたリスクを避けられます。autofsは、どのディレクトリ配下を自動マウントの対象にするかを指定する親設定ファイル/etc/auto.masterと、そこから参照される個別のマップファイル（下の例では/etc/auto.nfs）で実際のマウント先を記述する、2段階の構成になっています。
/etc/auto.master に以下を追記
/mnt/nfs /etc/auto.nfs
/etc/auto.nfs（マップファイル）
data -rw,soft fileserver:/export/data$ sudo systemctl restart autofs # 正常時は無出力この設定により、/mnt/nfs/data にアクセスした瞬間に自動でマウントされます。/etc/fstabへの恒久的な記述と違い、使わないときはマウントされていない状態を保てます。既定のアンマウントまでのタイムアウトは5分（300秒）で、/etc/auto.masterの行末に--timeout=60のように指定することで変更できます。マップファイルの記述には、この例で使った-rw,softのようなマウントオプション指定のほか、-fstype=nfsのようにファイルシステムの種類を明示する書き方もあります。
softは、サーバーが応答しない場合にタイムアウトしてエラーを返しますが、hard（既定値）はサーバーが復旧するまで無期限に待ち続けます。autofsの例でsoftを指定しているのは、応答のないサーバーへのアクセスでプロセスが無限に固まってしまう事態を避けるためです。ただし、softはタイムアウト時にデータの一部が失われる可能性もあるため、書き込みの整合性が重要な用途ではhardのほうが安全とされる場合もあります。
間接マップと直接マップ
autofsのマップファイルには、上で見た「間接マップ（indirect map）」のほかに「直接マップ（direct map）」があります。
| 種類 | 特徴 |
|---|---|
| 間接マップ | auto.masterで指定したベースディレクトリ配下に、マップファイルのキー名でサブディレクトリが作られる（例： /mnt/nfs/data） |
| 直接マップ | auto.masterのマウントポイントに /- を指定し、マップファイル内で絶対パスのマウントポイントを直接指定する |
/etc/auto.master（直接マップの例）
/- /etc/auto.direct
/etc/auto.direct
/mnt/project1 -rw,soft fileserver:/export/project1間接マップは、多数のホームディレクトリを同じルール（例： /home/ユーザー名）で自動マウントしたいような、規則的なパターンに向いています。一方、直接マップは、マウント先のパスがそれぞれ異なる場合や、autofsで管理していることを利用者に意識させたくない場合に使われます。実運用では、LDAPやNIS経由でマップ情報を配布し、多数のクライアントで同じ自動マウント設定を共有することもよく行われます。
リムーバブルメディアの扱い
USBメモリなどを接続すると、多くのデスクトップ環境では自動的にマウントされます。CUI環境で手動マウントする場合は、これまでと同様に mount を使います。
$ lsblk # 接続されたデバイス名を確認
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 40G 0 disk
├─sda1 8:1 0 1G 0 part /boot
└─sda2 8:2 0 39G 0 part /
sdc 8:32 1 32G 0 disk
└─sdc1 8:33 1 32G 0 part
$ blkid /dev/sdc1 # ファイルシステムの種類やUUIDを確認
/dev/sdc1: LABEL="MYUSB" UUID="A1B2-C3D4" TYPE="exfat" PARTUUID="9f8e7d6c-01"
$ sudo mount /dev/sdc1 /mnt/usb # 正常時は無出力
$ sudo umount /mnt/usb # 取り外す前に必ずアンマウント（正常時は無出力）この行のこの値に注目： lsblkのRM（removable）列が1のデバイスがリムーバブルメディアです。blkidのTYPEで実際のファイルシステム形式（この例ではexfat）が分かるため、mount時に-tで種類を明示する必要があるかどうかを事前に判断できます。
デスクトップ環境では、udisks2とudisksctlを通じて、一般ユーザーが特別な権限なしにリムーバブルメディアをマウント・アンマウントできる仕組みが提供されています。GUIのファイルマネージャーがUSBメモリの抜き差しを検知して自動マウントする際も、内部的にはこのudisks2が使われています。
$ udisksctl mount -b /dev/sdc1 # sudo不要でマウント（udisks2経由）
Mounted /dev/sdc1 at /media/kosuke/MYUSB.
$ udisksctl unmount -b /dev/sdc1
Unmounted /dev/sdc1.この行のこの値に注目： udisksctl mountの応答に実際のマウント先パス（/media/ユーザー名/ラベル名）が表示されます。手動mountではマウント先を自分で指定しますが、udisksctl経由では実行したユーザー名とデバイスのラベルから自動的にパスが決まる点が異なります。
umountを実行しても「device is busy」のようなエラーで失敗することがあります。これは、そのマウントポイント配下を作業ディレクトリにしているシェルセッションが残っていたり、該当ファイルを開いたままのプロセスが存在したりする場合に起こります。lsof +D /mnt/usbやfuser -m /mnt/usbで、どのプロセスがそのマウントポイントを使用中かを特定できます。
umount -l（lazy umount）や電源を切って強制的に取り外すのは避けるべきです。特にlazy umountはマウントポイントを即座に切り離しますが、実際のファイルシステムの解放（書き込みキャッシュのフラッシュ完了）は使用中のプロセスが終了するまで遅延されるため、データの不整合につながる可能性があります。まずは使用中のプロセスを正しく終了させることを優先しましょう。
smartctl — ディスクの健全性監視
物理ディスクの多くはS.M.A.R.T.（Self-Monitoring, Analysis and Reporting Technology）という自己診断機能を持っています。smartctl コマンドでこの情報を読み取り、故障の予兆を早期に察知できます。
$ sudo smartctl -a /dev/sda # 詳細な健全性情報を表示
SMART overall-health self-assessment test result: PASSED
ID# ATTRIBUTE_NAME VALUE WORST THRESH TYPE RAW_VALUE
5 Reallocated_Sector_Ct 100 100 036 Pre-fail 0
9 Power_On_Hours 098 098 000 Old_age 9821
194 Temperature_Celsius 067 055 000 Old_age 33
$ sudo smartctl -H /dev/sda # 健全性テストの結果のみ（PASSED/FAILED）
SMART overall-health self-assessment test result: PASSEDこの行のこの値に注目： RAW_VALUE列が実際の測定値で、Reallocated_Sector_Ctが0でなく増加傾向にあれば要注意です。Temperature_Celsiusの33（摂氏）のように、RAW_VALUEの解釈は属性ごとに異なる点に注意します。
自己診断テストの実行と注目すべき属性
-H の結果だけでなく、能動的な自己診断テストを実行して確認する方法もあります。
$ sudo smartctl -t short /dev/sda # 数分で終わる簡易テストを開始
Testing has begun.
Please wait 2 minutes for test to complete.
$ sudo smartctl -t long /dev/sda # 全セクタを検査する詳細テスト（数十分〜数時間）
Testing has begun.
Please wait 65 minutes for test to complete.
$ sudo smartctl -l selftest /dev/sda # テスト結果のログを表示
Num Test_Description Status Remaining LifeTime(hours)
# 1 Short offline Completed without error 00% 9821
# 2 Extended offline Completed without error 00% 9800この行のこの値に注目： テスト開始直後はTesting has begunとだけ表示され、テスト自体はバックグラウンドで進行します。完了後に-l selftestで結果を確認し、StatusがCompleted without errorであれば問題なし、それ以外（Completed: read failureなど）が表示された場合はディスクの異常を示します。
| SMART属性（例） | 意味 |
|---|---|
| Reallocated_Sector_Ct | 代替処理された不良セクタの数。増加傾向が続く場合は要注意 |
| Pending_Sector_Ct | 不良の疑いがあり再割り当て待ちのセクタ数 |
| Power_On_Hours | 累積稼働時間 |
| Temperature_Celsius | ディスクの現在温度。高温状態が続くと故障率が上がるとされる |
| UDMA_CRC_Error_Count | データ転送時のCRCエラー回数。ケーブルの接触不良を示すことが多い |
近年主流のNVMe SSDでは、smartctlの代わりにnvme-cliパッケージのnvme smart-log /dev/nvme0を使うのが一般的です（比較的新しいsmartctlはNVMeにも対応していますが、属性の意味合いがHDDとは異なります）。SSD特有の指標として、書き込み可能な残り寿命の推定値であるPercentage_Used（NVMe）やMedia_Wearout_Indicator（SATA SSD）にも注目する価値があります。
smartdデーモン（smartmontoolsパッケージに含まれる）を常駐させ、/etc/smartd.confで定期的な自己診断テストの自動実行としきい値超過時のメール通知を設定しておくのが実運用では一般的です。
リムーバブルメディアのファイルシステム形式
USBメモリやSDカードは、他のOS（Windows・macOSなど）とも共有できるよう、Linux専用のext4ではなくexFATやFAT32といった形式でフォーマットされていることが多くあります。Linuxでこれらを読み書きするには、対応するドライバやツールが必要です。
$ sudo apt install exfatprogs # exFATの作成・修復ツール（Debian系、ディストリによりexfat-utilsの場合も）
Reading package lists... Done
...（省略）
Setting up exfatprogs (1.2.1-1) ...
$ sudo mkfs.exfat -n MYUSB /dev/sdb1
exfatprogs version : 1.2.1
Creating exFAT filesystem(MYUSB, cluster size=131072)
...
Writing volume boot record: done
exFAT format complete!
$ sudo fsck.exfat /dev/sdb1
exfatprogs version : 1.2.1
sector size : 512
cluster size : 131072
total sectors : 62914560
Checking file system
[NORMAL] file system is cleanこの行のこの値に注目： fsck.exfatの最終行が[NORMAL] file system is cleanであれば問題なしです。破損している場合は[FIXED]のような表示とともに修復内容が示され、それでも直らない場合は再フォーマットが必要になります。
FAT32には「1ファイルあたり4GBまで」という制限があるため、大きな動画ファイルなどを扱う場合はexFATを選ぶのが実務では一般的です。逆にLinux専用の外付けディスクとして使うのであれば、パーミッションやシンボリックリンクをフルに扱えるext4を選ぶほうが機能面で有利です。