Linuxでファイルやディレクトリのディスク使用量を効率的に表示する方法の実務上の結論は「filesystem容量はdf -hT、inodeはdf -i、directory別はdu -shで確認します。dfとduの差を同じmetricとして単純に差し引かず、mount単位で調査します。」です。容量調査ではfilesystem block、inode、directory treeの三つを別metricにします。dfとduの差を単純な計算誤りにせず、mount identityと取得時刻を揃えて原因層を探します。
df・du・inode使用率の役割
dfはfilesystem全体のblockと空き、df -iはinode、duはdirectory treeから見えるentryの使用量を示します。同じ『disk使用量』でも母集団が違います。deleted-open file、reserved block、filesystem metadata、snapshot、container overlay、thin provisioningがあるため、dfとduの差を単純な計算誤差と扱いません。
filesystem逼迫はdf -h path、機械判定は明示block size、inodeはdf -i、directory内訳はdu -x –max-depth、mount情報はfindmntで確認します。-hの丸め値を閾値計算に使わず、target pathがどのmountへ属するかを固定します。別filesystemとnetwork mountを走査するかを先に決めます。
block・inode・directory usageの母集団を揃える
- 対象pathが属するmountを確認する
- block容量かinode枯渇かを分ける
- dfとduの測定範囲をそろえる
- snapshot、reserved space、deleted-open fileを確認する
df対象とdu rootが同じmountかfindmntで確定します。取得中にmountが切り替わった場合やI/O負荷上限を超えた場合は走査を止め、snapshotまたは低負荷windowで最初から採り直します。
df・du・findmntをmount単位で照合する
対象filesystemの容量を表示
df -hT -- ./projectpathを指定して該当mountのtype、size、used、availableを確認します。
inode使用量を表示
df -i -- ./project小file大量作成ではblock容量が余っていてもinodeが不足し得ます。
directory合計を確認
du -shx -- ./project-xで別filesystemを越えず、permission errorを別記録にします。
直下ごとの大きさを比較
du -h -x --max-depth=1 -- ./project | sort -hproductionではrecursive I/O負荷と実行時間帯を確認します。
mount sourceとoptionを確認
findmnt -T ./project -o TARGET,SOURCE,FSTYPE,OPTIONSoverlay、network、read-only等の前提を記録します。
見えない使用量とstorage層
dfはfilesystem allocation、duはdirectory treeから見えるentryのusageです。deleted-open fileはdirectoryから見えなくてもprocessがcloseするまでspaceを保持し、reserved blocksやsnapshot、metadata、copy-on-writeも差の原因です。Availableはfreeと同義でないfilesystemがあります。
dfのUse%はfilesystemが報告するblock使用率で、root reserved block等により単純なused/(used+available)と見え方が異なる場合があります。inodeが尽きればblockに空きがあっても新規fileを作れません。duとの差が大きいときはopen削除file、snapshot、permission未計測、mount隠蔽、backend allocationを候補別に調べます。
df対象pathが存在しない、mount切断、stale network情報、duのpermission error、走査中更新、container namespace違いを分けます。監視値を0や前回値で埋めると障害を隠すため、取得失敗metricを別に出します。human-readable unitのK/M/Gを単純文字sortせず、整数byteへ統一します。
open削除file・snapshot・取得失敗を分ける
- dfとduが必ず一致すると考える
- inode使用率を見ない
- overlay/containerのlayerをhost容量と混同する
- permission errorを無視してduを完全値とする
- 容量不足を即時削除だけで解決する
df高使用・du低使用ならopen済み削除file、snapshot、reserved blockを候補にします。permission warning付きduを完全値とせず、processとmount情報を保全してowner権限で再収集します。
容量確認だけでlogやcacheを削除しません。まずmount、owner process、retention policy、backup、service影響を確認します。duをroot全体へ頻繁に走らせず、-xと対象絞り込みを使います。緊急時も未知fileの削除ではなくservice ownerとrollbackを明記します。
容量不足時にも大きいfileを即削除せず、owner、open process、retention、backup、replication、復元時間を確認します。databaseやlogをrmで消す手順は作らず、applicationのrotation/retention機能を使います。du全走査のI/O、remote mount、snapshot操作の影響を評価し、緊急時の変更は承認とrollbackを分けます。
容量監視を安全に検証する
既知size tree、many small files、sparse、別mount、read不可directoryをsampleにします。df blocks/inodes、du通常/apparent、findmnt、error件数を表にし、監視thresholdと復旧後の再取得方法を決めます。
小file多数でinodeを使うsample、既知size、sparse、hard link、別mount、read不可directoryをtest環境へ用意します。df block/inode、du通常/apparent/-x、findmntの結果とstatusを期待表へ照合します。open削除fileやsnapshotの検証は隔離環境だけで行い、production dataを削除して再現しません。
mount identity付きでblockとinodeを監視する
監視はblock使用率、available bytes、inode使用率、収集status、mount identityを別metricにします。directory scanは頻度、root、-x、timeout、最大I/Oを定義し、storage APIがある基盤ではbackend metricも取り込みます。alertには増加source、owner、未計測pathを添え、自動削除ではなくrunbook選択へ接続します。
逼迫層からretention・拡張担当へ渡す
空きblockはdf、inodeはdf -i、directory別増加はdu、open削除fileはprocess調査、snapshot/thin poolはstorage管理planeを使います。container内の値とhost/backend値を同列に比較しません。どの層が逼迫したかを特定してから、retention変更、拡張、cleanupの担当workflowを選びます。
合格はblock逼迫、inode逼迫、open削除file、読取不可treeのfixtureを別alertへ分けられることです。mount IDが変わったrunは破棄し、削除せずに担当queueへエスカレーションします。
コメント