Linuxを使っていると、突然よく分からないエラーに出会うことがあります。
今回の始まりは、AlmaLinuxへSSH接続したときに表示されたこのメッセージでした。
zsh: locking failed for /home/user/.zsh_history:
デバイスに空き領域がありません: reading anyway「デバイスに空き領域がありません」。
そんなにファイルを置いた記憶はありません。
しかも、このAlmaLinuxはVirtualBox上の学習用環境です。普段はVS CodeのRemote SSHで接続し、PythonやRustなどの学習に使っています。
何が起きているのか、調べてみました。
まずはdfで空き容量を確認する
ディスク容量といえば、まずはこれです。
df -h結果を見ると、少し不思議な状態になっていました。
/dev/mapper/almalinux-root 42G 13G 29G 31% /
/dev/mapper/almalinux-home 21G 21G 20K 100% /homeルート / には29GBも空きがあります。
ところが、
/home 100%でした。
空き容量は、わずか20KB。
これでは .zsh_history のロックファイルすら作れないのも納得です。
Linuxでは一つのディレクトリツリーに見えていても、/ と /home が別のファイルシステムになっていることがあります。
今回はまさにそれでした。
何が/homeを使っているのか
次に、自分のホームディレクトリを調べました。
du -h --max-depth=1 ~ | sort -hすると、大きなディレクトリがいくつか見つかりました。
1.1G /home/user/.cabal
3.7G /home/user/.rustup
6.4G /home/user/.vscode-server
6.9G /home/user/.ghcup
20G /home/userなるほど。
Haskell、Rust、そしてVS Code。
学習用にいろいろ試してきた結果が、きれいに積み上がっていました。
特に気になったのが、
.vscode-server 6.4GBです。
VS Code Remote SSHはリモート側にもいろいろ置いている
VS CodeのRemote SSHは便利です。
Windows側でVS Codeを起動し、SSH経由でLinux上のファイルを編集できます。
見た目だけだと「WindowsのVS CodeからLinuxのファイルを触っている」ようにも感じます。
しかし、実際にはLinux側にも .vscode-server が作られます。
さらに調べてみました。
du -h --max-depth=1 ~/.vscode-server | sort -hすると、
322M .vscode-server/data
757M .vscode-server/extensions
5.2G .vscode-server/cli
6.4G .vscode-servercli だけで5.2GBあります。
さらに掘ります。
du -sh ~/.vscode-server/cli/servers/*すると、VS Code Serverが何世代も残っていました。
685M Stable-08d...
701M Stable-520...
652M Stable-645...
701M Stable-88e...
697M Stable-df5...
671M Stable-e4c...1世代あたり、およそ650〜700MB。
さらに .staging という途中状態のディレクトリも残っていました。
VS Codeを長期間Remote SSHで使っているうちに、こうしたファイルが積み重なっていたようです。
不要なファイルを整理する
まず、残っていた .staging を整理しました。
その結果、
/home 100%だった状態が、
/home 95%まで回復しました。
さらに、利用履歴に載っていない古いVS Code Serverを一つ削除。
/home 92%まで下がりました。
緊急事態は脱しました。
ただし、まだ92%。
今後もRustやVS Code Remote SSHを使うことを考えると、少し心許ない状態です。
そもそも/homeが21GBしかない
改めて構成を確認しました。
lsblksda 67.9G
├─sda1 1G /boot
└─sda2 66.9G
├─almalinux-root 41.1G /
├─almalinux-swap 5.7G
└─almalinux-home 20.1G /homeルートには余裕がありますが、/home は約20GBです。
開発環境として使い続けるなら、もう少し余裕がほしい。
そこでVirtualBoxの仮想ディスク自体を10GB増やすことにしました。
変更前の容量は69534MBでした。
10GiBは10240MBなので、
69534 + 10240 = 79774
となります。
そこで、次のコマンドを実行しました。
VirtualBoxの仮想ディスクを10GB増やす
"C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" modifymedium disk "C:\Users\<ユーザー名>\VirtualBox VMs\alma_2026\alma2.vdi" --resize 79774仮想ディスクは約68GB。
これを約78GBへ拡張しました。
AlmaLinuxを起動して確認すると、
sda 77.9G
sda2 66.9Gとなりました。
ここが面白いところです。
仮想ディスクを10GB増やしても、Linuxの /home は1バイトも増えていません。
箱を大きくしただけだからです。
パーティションを広げる
次に growpart を使いました。
AlmaLinuxでは入っていなかったので、
sudo dnf install -y cloud-utils-growpartでインストール。
そして、
sudo growpart /dev/sda 2を実行します。
確認すると、
sda 77.9G
└─sda2 76.9Gとなりました。
これで第2パーティションが約10GB広がりました。
しかし、まだ /home は増えていません。
LVMに空き容量ができた
LVMの状態を確認します。
sudo pvs
sudo vgsすると、
VG VSize VFree
almalinux <76.90g <10.00g約10GBの空きができています。
この10GBを /home に渡します。
今回はLVMを使っているため、論理ボリュームを拡張できます。
sudo lvextend -r -l +100%FREE /dev/mapper/almalinux-homeそして、
df -h /homeを確認。
/dev/mapper/almalinux-home 31G 19G 12G 61% /home無事、
/home 21GB → 31GBになりました。
使用率も、
100% → 61%まで改善しました。
「PCが遅い」の裏側を見る
今回の調査中、CPUやメモリも確認しました。
free -h
uptimeメモリは11GB中、利用可能が約10GB。
ロードアベレージも、
0.01, 0.06, 0.08程度でした。
CPUやメモリにはかなり余裕があります。
一方で /home は100%になっていました。
「PCが遅い」と感じたとき、CPUやメモリだけを見るのでは足りないことがあります。
free -h
uptime
df -h
du -sh ~/.vscode-serverこうして複数の情報を見ることで、少しずつ原因を絞り込めます。
エラーは学習の入口になる
今回の始まりは、たった一行のエラーでした。
デバイスに空き領域がありませんそこから、
zshのエラー
↓
dfでファイルシステムを確認
↓
/homeが100%
↓
duで容量を調査
↓
.vscode-serverが6.4GB
↓
VS Code Serverが複数世代残っていた
↓
不要ファイルを整理
↓
VirtualBoxの仮想ディスクを拡張
↓
パーティションを拡張
↓
LVMを拡張
↓
/homeが21GBから31GBへと、かなりいろいろなLinuxの仕組みに触れることになりました。
Linuxを勉強していると、エラーはできれば避けたいものに見えます。
でも実際には、こういう「なぜ？」を追いかけたときに、ファイルシステムやLVM、VS Code Remote SSHの裏側がつながって見えてきます。
今回もまた、いいRetryになりました。
この記事で出てきた用語
今回の作業では、ディスク周りの用語がいくつも登場しました。
自分自身の整理も兼ねて、簡単にまとめておきます。
VirtualBox / VDI
VirtualBoxは、PCの中に仮想的なコンピュータを作るための仮想化ソフトウェアです。
今回のAlmaLinuxもVirtualBox上で動いています。
**VDI（Virtual Disk Image）**は、VirtualBoxで仮想マシンのディスクとして使われるファイル形式の一つです。
今回最初に行った、
VBoxManage modifymedium disk ... --resize 79774は、この仮想ディスクそのものを大きくする操作でした。
ただし、VDIを大きくしただけではLinux内部のパーティションや /home は大きくなりません。
パーティション
1台のディスクを論理的に区切った領域です。
今回の環境では、
sda
├─sda1
└─sda2という構成になっていました。
/dev/sda がディスク全体、/dev/sda1 や /dev/sda2 がその中に作られたパーティションです。
今回はVirtualBox側でディスクを大きくしたあと、
sudo growpart /dev/sda 2によって第2パーティションである /dev/sda2 を拡張しました。
LVM
**LVM（Logical Volume Manager）**は、Linuxでストレージ領域を柔軟に管理する仕組みです。
通常のパーティションをそのまま使うのではなく、
ディスク・パーティション
↓
PV
↓
VG
↓
LV
↓
ファイルシステムという層を作って管理します。
一見すると複雑ですが、あとから論理ボリュームを大きくしたり、複数のストレージをまとめたりできるのが利点です。
今回 /home を比較的簡単に10GB増やせたのも、LVMを使っていたからです。
PV（Physical Volume）
Physical Volume。
LVMがストレージとして利用するための土台です。
今回の場合は、
/dev/sda2がPVとして使われていました。
pvs コマンドで確認できます。
sudo pvsVG（Volume Group）
Volume Group。
1つ以上のPVをまとめて作る「ストレージのプール」のようなものです。
今回のVGは、
almalinuxでした。
vgs コマンドで確認できます。
sudo vgs今回ディスクを拡張したあとに表示された、
VFree <10.00gは、「almalinuxというVGの中に、まだどのLVにも割り当てていない領域が約10GBある」という意味です。
LV（Logical Volume）
Logical Volume。
VGの中から必要な容量を切り出して作る論理的なストレージ領域です。
今回の環境には、
almalinux-root
almalinux-swap
almalinux-homeというLVがありました。
そのうち、
almalinux-homeが /home に使われています。
今回は、
sudo lvextend -r -l +100%FREE /dev/mapper/almalinux-homeによって、VGに残っていた空き領域をこのLVへ追加しました。
ファイルシステム
ディスク上にファイルやディレクトリを保存・管理するための仕組みです。
LinuxではXFSやext4などがよく使われます。
ディスクやLVそのものを大きくしても、ファイルシステムが以前のサイズのままでは、その領域をファイル保存には利用できません。
今回使った lvextend の -r オプションは、LVの拡張に合わせてファイルシステム側も拡張するためのものです。
マウント
Linuxでは、ファイルシステムを /home や /boot などのディレクトリに接続して利用します。
これをマウントと呼びます。
今回、
df -h /homeで、
/dev/mapper/almalinux-home 31G 19G 12G 61% /homeと表示されたのは、almalinux-home というLV上のファイルシステムが /home として利用されていることを示しています。
df
ファイルシステムの使用量や空き容量を確認するコマンドです。
df -h今回のトラブルを発見する決め手になったコマンドです。
-h を付けると、GBやMBなど人間が読みやすい単位で表示されます。
du
ファイルやディレクトリが実際にどれくらい容量を使っているか調べるコマンドです。
du -h --max-depth=1 ~ | sort -h今回はこれによって、.vscode-server、.ghcup、.rustup などが大きな容量を使っていることが分かりました。
df が「ファイルシステム全体を見る」コマンドなら、du は「どのファイルやディレクトリが使っているのかを探す」ためのコマンド、と考えると分かりやすいです。
VS Code Remote SSH / .vscode-server
VS Code Remote SSHを使うと、手元のPCからSSH接続したLinux環境をVS Codeで操作できます。
その際、リモート側には、
~/.vscode-serverというディレクトリが作られ、VS Code Serverや拡張機能などが保存されます。
今回の環境では、このディレクトリだけで約6.4GBありました。
Remote SSHは単に「SSH経由でファイルを編集している」だけではなく、リモート側にもVS Codeを支える仕組みが配置されている、ということが今回の調査でよく分かりました。
今回の構造をもう一度整理
今回触ったものを上から並べると、こうなります。
VirtualBox
│
└─ VDI（仮想ディスク）
│
└─ /dev/sda
│
├─ /dev/sda1
│
└─ /dev/sda2（パーティション）
│
└─ PV
│
└─ VG: almalinux
│
├─ LV: root → /
├─ LV: swap
└─ LV: home → /home普段Linuxを使っているだけなら、ここまで意識することはあまりありません。
でも /home が100%になったことで、この何層にもなっているストレージの構造を実際にたどることになりました。
エラーから調べ始めた結果、Linuxのストレージ構造そのものを学ぶことになった。
これも今回のRetryで得られたものの一つです。
コメント