Centos Stream 8 OS를 설치하는 동안 /var에 10GB의 크기를 지정하면 충분할 것이라고 생각했지만 docker를 사용하기 시작한 후에는 /var 파티션에서 다음과 같이 너무 많은 공간을 차지한다는 사실을 발견했습니다. df 명령:
[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의 /경우드물게시스템이 제대로 관리되면 10GiB 이상의 공간을 사용합니다.
귀하의 LVM이 최적이 아닐 뿐만 아니라: ESP와 /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 논리 볼륨을 사용하고 있습니다.
var를 확장하기 위해 할당할 수 있는 볼륨 그룹에 사용되지 않은 공간이 남아 있을 수 있습니다.
사용하지 않는 공간이 남아 있지 않거나 너무 적은 경우 다음을 수행할 수 있습니다.스왑 LVM을 줄이거나 제거하십시오./var를 확장하기 위해 확보된 공간을 가져옵니다.
그러면 시스템이 그대로 유지되며 일반적으로 온라인에서도 수행할 수 있습니다.
이에 대한 접근 방식은 (테스트되지 않은 명령이므로 완전히 복사하지 말고 원칙은 타당해야 함) 라인을 따르는 것입니다.
스왑 파티션을 오프라인으로 전환하는 동안 대용량 루트 파일 시스템에 대체 파일로 임시 또는 영구 스왑 파일을 만듭니다.
dd if=/dev/zero of=/swap-file count=65536 bs=1Mmkswap /swap-fileswapon /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.2GB는 백업하기 어렵지 않습니다. 따라서 rootfs 파일 시스템 유형에 따라 다음과 같은 옵션이 있습니다.
ext4인 경우 내부에서 축소할 수 있습니다.
ext4는 오프라인으로만 축소할 수 있으므로 ArchISO와 같은 다른 시스템으로 재부팅하세요.
lvs파티션이 표시되는지 확인한 다음e2fsck -f /dev/mapper/cs-rootresize2fs -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.2GB의 여유 공간을 쉽게 찾을 수 있습니다. 스왑 볼륨의 크기가 너무 클 가능성이 높습니다.)lvremove루트 볼륨을 삭제하고 적절한 크기로 다시 생성합니다. 이번에는 ext4로 포맷하는 것을 권장합니다.rsync -avHAXx /somewhere /your-rootfs다시 복사합니다.- 필요한 경우 GRUB 구성을 업데이트하세요. AFAICT LV ID는 종종 힌트로 기록되지만
grub.cfg저는 CentOS에 익숙하지 않습니다(Debian에서는 간단히update-grub). - 위와 같이 VG에 여유 공간을 할당합니다.
내가 지적하고 싶은 다른 참고 사항:
- EFI 시스템 파티션(ESP)이 너무 큽니다. 일반적인 Linux 서버의 경우 256MB면 충분합니다(저는 Ubuntu 서버에서 128MB를 사용합니다). GRUB 바이너리와 매우 기본적인 버전의
grub.cfg. /boot자체 볼륨으로 살 필요는 없습니다. GRUB은 LVM과 rootfs 파일 시스템을 잘 읽을 수 있습니다.- 서버 설계에 따라
/root크기가 너무 클 수도 있습니다(저는 Proxmox VE 서버에 16GB를 사용합니다. 호스트에 데이터를 넣을 계획이 없습니다). - 64GB의 스왑 공간이 정말로 필요합니까? 보통 8GB만 있어도 괜찮습니다.