☰

Centos Stream 8 で /var パーティションを拡張する

tag-icon • tag-icon centos docker filesystems lvm partition
Centos Stream 8 で /var パーティションを拡張する

Centos Stream 8 OS のインストール中に、/var に 10 GB のサイズを指定しましたが、これで十分だと思いました。しかし、docker を使い始めてから、df コマンドで表示されるように、/var パーティションで多くのスペースを占有していることに気付きました。

[root@compute-07 ~]# df -h
Filesystem           Size  Used Avail Use% Mounted on
devtmpfs              28G     0   28G   0% /dev
tmpfs                 28G     0   28G   0% /dev/shm
tmpfs                 28G  179M   28G   1% /run
tmpfs                 28G     0   28G   0% /sys/fs/cgroup
/dev/mapper/cs-root  371G  8.2G  363G   3% /
/dev/mapper/cs-home  100G  2.0G   98G   2% /home
/dev/mapper/cs-var    10G  9.0G  1.1G  90% /var
/dev/sda2            2.0G  412M  1.6G  21% /boot
/dev/sda1            2.0G  7.3M  2.0G   1% /boot/efi
/dev/mapper/cs-tmp    10G  105M  9.9G   2% /tmp
tmpfs                5.5G   16K  5.5G   1% /run/user/42
overlay               10G  9.0G  1.1G  90% 

/var/lib/docker/overlay2/77f74478297ca61595f0003d35c7323ec627adb44d94cef92c2b4a3c97319a66/merged
overlay               10G  9.0G  1.1G  90% /var/lib/docker/overlay2/5eeb399ce4a3c0d8065d63123985269a359fa66f4d20a8486326e466a48a0128/merged
overlay               10G  9.0G  1.1G  90% /var/lib/docker/overlay2/08d42ca66e3a5974bc305b502bca2aa4d22aa7ddcab6ea14c6af300b3abb3a70/merged
overlay               10G  9.0G  1.1G  90% /var/lib/docker/overlay2/1a45cb32b127fdf8f5c1483385139a865fdc69260ec20f3dcd4c56ad6890f909/merged
overlay               10G  9.0G  1.1G  90% /var/lib/docker/overlay2/ebb9af8edee824a4013dcd526e33e22272283bdee508fd43208fade557def728/merged
overlay               10G  9.0G  1.1G  90% /var/lib/docker/overlay2/41d55822108d04c85f348dc134fe6929b0e67f6b3bd7e0af147633bfd3a252c1/merged
overlay               10G  9.0G  1.1G  90% /var/lib/docker/overlay2/5cf3e8e06e9b4c2e6ed65164d91aed19f63d55e91524d6563e9f16b6709d29be/merged
overlay               10G  9.0G  1.1G  90% /var/lib/docker/overlay2/1d1eda94e68596b00d0cabcc75a7c91999a1c845ebd02c733bb9f00ac66a26f0/merged
overlay               10G  9.0G  1.1G  90% /var/lib/docker/overlay2/bc9e9a28c6761ad89a9457110642156ebd2b4d77de841f2a3ac9ffbaa90e4b63/merged

tmpfs                5.5G     0  5.5G   0% /run/user/0

これはlsblkコマンドの出力です。/varは/と/homeとは別のパーティションにあるため、サイズを変更したり、別のパーティションを作成して/varにリンクしたりする方法を見つけることができませんでした。

[root@compute-07 ~]# lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda           8:0    0 558.4G  0 disk 
├─sda1        8:1    0     2G  0 part /boot/efi
├─sda2        8:2    0     2G  0 part /boot
└─sda3        8:3    0 554.4G  0 part 
  ├─cs-root 253:0    0 370.4G  0 lvm  /
  ├─cs-swap 253:1    0    64G  0 lvm  [SWAP]
  ├─cs-tmp  253:2    0    10G  0 lvm  /tmp
  ├─cs-home 253:3    0   100G  0 lvm  /home
  └─cs-var  253:4    0    10G  0 lvm  /var
sr0          11:0    1  1024M  0 rom

データを失うことなくこのパーティションのサイズを変更する方法はありますか。

答え1

いいえ。実際、システム内のスペースのほとんどは、/var通常var利用可能なデータは、データベース、Docker、ログなど、Linux/のめったにシステムが適切に管理されている場合、10 GiB を超えるスペースが使用されます。

LVM が最適ではないだけではありません。ESP で無駄にしていたスペースに、Debian のインストール全体といくつかのサービスを収めることになります/boot。(私はシステムに 4GiB を割り当てて VM を作成する習慣がありました。十分すぎるほどです。)

最善の解決策は、大きすぎるルート ファイル システムを縮小することですが、これはオンラインでは実行できません。レスキュー メディアを起動し、VG をアクティブ化してから、ファイル システムと論理ボリュームを縮小する必要がありますが、パーティションのサイズを考えると、かなりの時間がかかる可能性があります。また、混乱を招く可能性もあります。急いでいる場合は、工夫を凝らすことができます。ルートにディレクトリを作成し、Docker データをそこに移動し、それを Docker データが存在する var にバインド マウントします。当面は、Docker とすべてのコンテナーを停止する必要があります。次のようになります。

systemctl stop docker.service
mkdir /var-lib-docker
mv /var/lib/docker/* /var-lib-docker
mount --bind /var-lib-docker /var/lib/docker
systemctl start docker.service

こうすることで、Docker は通常の場所でも利用できる一方で、特大のルート ファイル システム上のスペースを使用するようになります。 に/etc/fstab次のエントリを追加して、この構成が再起動後も維持されるようにする必要があります。

/var-lib-docker /var/lib/docker none bind 0 0

しかし、これはかなり醜いハックであり、時間を稼ぐことはできますが、いくつかの問題も引き起こす可能性があることを覚えておいてください。そのため、ルートからスペースを取り戻し、/var適切に割り当てる機会を探してください。

そして、これを教訓にしましょう。最初から利用可能なすべてのスペースを割り当てないでください。一部 (大部分) は未割り当てのままにしておきます。スペースはいつでも簡単に追加でき、オンラインで実行できますが、スペースを再利用するのは非常に困難で時間がかかり、エラーが発生しやすく、ダウンタイムが必要になります。スペースを再利用する必要がないように管理するのが最善です。

答え2

代わりにこの答え

システムでは LVM 論理ボリュームを使用しています。

ボリューム グループ内に未使用の領域が残っている場合があり、これを拡張変数に割り当てることができます。

未使用のスペースが残っていない場合、または少なすぎる場合は、スワップLVMを削減または削除するそれによって解放されたスペースを使用して /var を拡張します。

これにより、システムはそのまま残り、通常はオンラインでも実行できます。

そのためのアプローチは、次のようなものになります（コマンドはテストされていないので、そのままコピーしないでください。ただし、原則は正しいはずです）。

  • スワップ パーティションをオフラインにしている間、代わりとして、サイズが大きすぎるルート ファイル システムに一時または永続的なスワップ ファイルを作成します。

    • dd if=/dev/zero of=/swap-file count=65536 bs=1M
    • mkswap /swap-file
    • swapon /swap-file

  • swapoff /dev/mapper/cs-swap スワップパーティションを無効にする

  • lvreducecs-swapを実行し、残りのLVMスワップパーティションを再度フォーマットし、mkswap小さい方のスワップスペースを再度アクティブ化します。swapon

  • または削除してくださいlvremove

新しく作成された空きLVMスペースを使用して、/var LVMボリュームを拡張し、ファイルシステムを拡張します。

lvextend -l +100%FREE --resizefs /dev/mapper/cs-var

答え3

dfあなたのファイルシステムが何であるかは教えないでくださいlsblk。ボリューム (パーティションまたは LV) を縮小するには、まずその上のファイルシステムを縮小する必要があります。rootfs の一般的な選択肢である ext4 は、オフラインで縮小できます。ただし、CentOS (および RHEL のようなディストリビューション) のデフォルトの FS 選択肢は XFS であり、現時点では縮小できません。

他の回答者が指摘しているように、rootfs 使用量 8.2 GB をバックアップするのは難しくありません。したがって、rootfs ファイルシステムの種類に応じて、次のオプションがあります。

ext4 の場合は、その場で縮小できます。

  • ext4 はオフラインでのみ縮小できるため、ArchISO などの別のシステムを再起動します。

  • lvsパーティションが表示されていることを確認してからe2fsck -f /dev/mapper/cs-root

  • resize2fs -M -p /dev/mapper/cs-root

    • あるいは、希望する rootfs サイズがわかっている場合は、次のように指定することもできます-M。

      resize2fs -p /dev/mapper/cs-root 15G

      基礎となるボリュームを縮小するためのスペースをいくらか残しておくことをお勧めします。

  • LVからスペースを取り戻すlvreduce -L 16G cs/root

  • ファイルシステムのサイズをボリュームサイズに戻します。resize2fs -p /dev/mapper/cs-root

  • これで、空きスペースを次の人に配布できるようになりました/var。lvextend -l +100%FREE cs/var

ただし、XFS の場合は、rootfs をバックアップして再作成するのが最善策です。

  • 上記のようにArchISOを起動します。
  • rsync -avHAXx /your-rootfs /somewhere(別のボリュームにあることを確認してください/somewhere。8.2 GB の空き領域を見つけるのは簡単です。スワップ ボリュームが大きすぎる可能性があります)
  • lvremoveルートボリュームを適切なサイズで再作成します。今回は ext4 にフォーマットすることをお勧めします。
  • rsync -avHAXx /somewhere /your-rootfs物事をコピーし直す。
  • 必要に応じて GRUB 構成を更新します - AFAICT LV ID はgrub.cfgヒントとしてよく書き込まれますが、CentOS についてはよく知りません (Debian では単に になりますupdate-grub)。
  • 上記のように VG に空き領域を割り当てます。

他に指摘したい点:

  • EFI システム パーティション (ESP) が大きすぎます。一般的な Linux サーバーの場合、256 MB あれば十分です (Ubuntu サーバーでは 128 MB を使用しています)。GRUB バイナリと の非常に基本的なバージョンのみを保持する必要がありますgrub.cfg。
  • /boot独自のボリュームに存在する必要はありません。GRUB は LVM と rootfs ファイルシステムを問題なく読み取ることができます。
  • サーバーの設計によっては、/rootサイズが大きすぎる可能性もあります (私は Proxmox VE サーバーに 16 GB を使用しています。ホストにデータを置く予定はありません)。
  • 本当に 64 GB のスワップ領域が必要ですか? 通常は 8 GB で十分です。

関連情報