EC2 'No space left on device' 파일 시스템에 남은 공간 없을 때 EBS 볼륨 크기 늘리기

 

Spring Cloud Config Server가 있는 EC2에 사용 가능한 용량이 없다는 문제로 해당 서버가 정상 동작하지 않자 해당 서버를 통해 설정 파일을 주입받는 모든 서버에 영향이..^^

용량이 이렇게 부족해 진 것은 불필요한 Batch작업이 해당 EC2에서 진행되고 있어서였고, 이는 처리하였다.

하지만 용량이 너무 작은 것으로 설정된 것 같긴 해서 이참에 볼륨 크기를 확장하기로.

 

아래 명령어로 파일시스템 용량을 확인해보았다. 

$ df -h

결과는 아래와 같았다. 

Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        978M     0  978M   0% /dev
tmpfs           986M     0  986M   0% /dev/shm
tmpfs           986M  101M  886M  11% /run
tmpfs           986M     0  986M   0% /sys/fs/cgroup
/dev/xvda1      8.0G  8.0G   20K 100% /
tmpfs           198M     0  198M   0% /run/user/1000
tmpfs           198M     0  198M   0% /run/user/0

AWS Console에서 해당 EC2의 스토리지의 볼륨디바이스를 보니 볼륨크기가 8Gib에 /dev/xvda로 설정되어 있는 것을 확인할 수 있었다. 

 

AWS Console에서 EBS Volume을 2배 (16Gib)로 변경해주었고, 아래 명령어로 연결된 블록 디바이스를 확인해보았다.

$ lsblk

루트 볼륨은 2배로 잘 커져 있었지만 파티션인 xvda1은 여전히 8Gib인 것을 볼 수 있을 것이다.

해당 파티션도 늘려주기 위해서 아래 명령어를 입력하였다 . 

$ sudo growpart /dev/xvda 1

그랬더니 아래와 같은 에러가...

mkdir: cannot create directory ‘/tmp/growpart.4699’: No space left on device
FAILED: failed to make temp dir

 

AWS 문서에 이와 같은 상황에서 할 수 있는 해결책을 제시해주었다. 

---

블록 디바이스에 남은 공간 없음 오류를 방지하려면 임시 파일 시스템 tmpfs를 /tmp 탑재 지점에 탑재합니다. 그러면 /tmp에 탑재된 10M tmpfs가 생성됩니다.

$ sudo mount -o size=10M,rw,nodev,nosuid -t tmpfs tmpfs /tmp

---

위와 같이 진행하고 아래 명령어를 입력하니 성공!

$ sudo growpart /dev/xvda 1

CHANGED: partition=1 start=4096 old: size=16773087 end=16777183 new: size=33550303 end=33554399

 

여기까지는 파티션의 크기를 늘린 것이고,

이제는 파일시스템에 변경된 파티션 크기를 적용해야 한다. 

그래서 아래의 명령어를 통해 적용해보려 했지만 에러가 뙇

$ sudo resize2fs /dev/xvda1

resize2fs 1.42.9 (28-Dec-2013)
resize2fs: Bad magic number in super-block while trying to open /dev/xvda1
Couldn't find valid filesystem superblock.

 

원인을 찾아보니 리눅스의 파일 시스템이 xfs라서 그런거라고 한다.. 아래 명령어를 입력해서 확인해 볼 수 있다. 

$ df -Th

Filesystem     Type      Size  Used Avail Use% Mounted on
devtmpfs       devtmpfs  978M     0  978M   0% /dev
tmpfs          tmpfs     986M     0  986M   0% /dev/shm
tmpfs          tmpfs     986M  101M  886M  11% /run
tmpfs          tmpfs     986M     0  986M   0% /sys/fs/cgroup
/dev/xvda1     xfs       8.0G  8.0G   20K 100% /
tmpfs          tmpfs     198M     0  198M   0% /run/user/1000
tmpfs          tmpfs     198M     0  198M   0% /run/user/0
tmpfs          tmpfs      10M     0   10M   0% /tmp

/dev/xvda1의 Type이 xfs로 되어 있다.  리눅스의 파일 시스템이 xfs일 경우 발생한다고 한다. 

 

이럴때는 resize2fs가 아닌 xfs_growfs를 써야 한다.

$ sudo xfs_growfs /dev/xvda1

아래의 메시지와 함께 정보들이 나열되면 성공!!

data blocks changed from 2096635 to 4193787

 

df -Th로 확인해보면~

Filesystem     Type      Size  Used Avail Use% Mounted on
devtmpfs       devtmpfs  978M     0  978M   0% /dev
tmpfs          tmpfs     986M     0  986M   0% /dev/shm
tmpfs          tmpfs     986M  100M  887M  11% /run
tmpfs          tmpfs     986M     0  986M   0% /sys/fs/cgroup
/dev/xvda1     xfs        16G  8.1G  8.0G  51% /
tmpfs          tmpfs     198M     0  198M   0% /run/user/1000
tmpfs          tmpfs     198M     0  198M   0% /run/user/0
tmpfs          tmpfs      10M     0   10M   0% /tmp

/dev/xvda1의 Size가 16G이고 Use%가 100%에서 51%로 줄어있는 것을 확인할 수 있다.

 

 

 

+ 

용량이 어느새 다시 찼다...

알고 보니 log 디렉토리에 로그파일이 수두룩 빽빽하게 쌓여서 용량을 다 잡아 먹고 있었던 것이다.

그래서 근본적인 해결을 하기로 하였고.

$ sudo du -x -h / | sort -h | tail -40 | sort -h -r

위 명령어를 통해 용량 차지 상위 순서대로 디렉토리 리스트를 뽑아봤고,

거기서 로그 디렉토리가 압도적인 것을 확인. 

스크립트를 짜서 15일에 한번씩 로그 파일들을 정리하기로 했다. 

 

 

끝!

 

 

 

출처

https://aws.amazon.com/ko/premiumsupport/knowledge-center/ebs-volume-size-increase/

https://velog.io/@hyeonseop/ec2-%EC%9A%A9%EB%9F%89-full%EC%9D%BC-%EB%95%8C-%EB%8C%80%EC%B2%98%EB%B2%95

https://nirsa.tistory.com/231