帮助中心

적용 환경

inode 부족 문제를 해결하는 순서

1. df -hT와 df -iT를 비교하여 실제 원인이 디스크 용량인지 inode인지 확인합니다.
2. inode 사용률이 높은 마운트 지점과 파일시스템 종류를 확인합니다.
3. du --inodes로 파일 수가 비정상적으로 많은 디렉터리를 찾습니다.
4. 삭제 대상을 먼저 출력해 검토한 뒤, 서비스 전용 명령이나 find -delete로 정리합니다.
5. 정리 후 inode 사용률과 서비스 상태를 다시 확인합니다.
6. 반복되는 환경은 파일 보존 정책, 로그 로테이션, 디스크 확장 또는 ext4 파일시스템 재구성을 검토합니다.

작업 전 주의사항

다음 항목을 먼저 확인합니다.

• 중요 데이터와 설정 파일의 최근 백업이 존재하는지 확인합니다.
• inode를 많이 사용하는 디렉터리가 애플리케이션의 필수 데이터 경로인지 확인합니다.
• 메일 큐, 데이터베이스, Docker 볼륨은 일반 rm 명령보다 해당 서비스의 관리 명령을 우선 사용합니다.
• 삭제 후 되돌릴 수 없는 파일은 충분히 검토하고, 가능하면 먼저 별도 저장소로 이동하거나 백업합니다.

inode 부족 여부 확인

1. 디스크 용량과 inode 사용률 비교

먼저 일반 디스크 사용량과 inode 사용량을 각각 확인합니다.

df -hT
df -iT

df -hT는 파일시스템의 저장 용량을 표시하고, df -iT는 전체 inode 수, 사용된 inode 수, 남은 inode 수와 사용률을 표시합니다. IUse%가 100%에 가깝고 IFree가 0이면 inode 부족이 직접적인 원인입니다.

2. 문제가 발생한 경로의 마운트 지점 확인

예를 들어 /var 아래에서 파일 생성 오류가 발생했다면 다음 명령으로 해당 경로가 속한 장치, 파일시스템 종류와 마운트 지점을 확인합니다.

findmnt -T /var -o SOURCE,FSTYPE,SIZE,USED,AVAIL,USE%,TARGET

문제가 다른 경로에서 발생했다면 /var를 해당 경로로 바꿉니다. 이후 진단 명령에서는 반드시 확인된 마운트 지점을 기준으로 작업해야 다른 파일시스템까지 불필요하게 검색하지 않습니다.

inode를 많이 사용하는 디렉터리 찾기

1. 최상위 디렉터리별 inode 사용량 확인

루트 파일시스템이 문제라면 다음 명령으로 같은 파일시스템 안에서 디렉터리별 inode 사용량을 확인합니다. -x 옵션은 다른 마운트 지점으로 넘어가지 않도록 제한하고, --inodes는 용량 대신 inode 사용량을 집계합니다.

sudo du --inodes -x -d 1 / 2>/dev/null | sort -n

출력 값이 큰 디렉터리를 확인한 뒤 한 단계씩 범위를 좁힙니다. 예를 들어 /var가 가장 크다면 다음과 같이 확인합니다.

sudo du --inodes -x -d 1 /var 2>/dev/null | sort -n
sudo du --inodes -x -d 1 /var/lib 2>/dev/null | sort -n

같은 방식으로 가장 큰 하위 디렉터리를 따라가면 inode를 대량으로 사용하는 실제 경로를 찾을 수 있습니다. 파일이 수백만 개라면 명령 실행 중 디스크 I/O가 증가할 수 있으므로 서비스 부하가 낮은 시간에 수행하는 것이 좋습니다.

2. 특정 디렉터리의 파일 수 확인

의심되는 디렉터리의 일반 파일 개수를 확인하려면 다음 명령을 사용합니다. /path/to/check는 실제 확인할 경로로 변경합니다.

sudo find /path/to/check -xdev -type f -printf '1\n' 2>/dev/null | wc -l

일반적으로 다음 경로에서 많은 소형 파일이 누적되는 경우가 있습니다. 실제 삭제 여부는 운영 중인 서비스와 파일 용도를 확인한 뒤 결정해야 합니다.

• /var/log: 회전되지 않은 애플리케이션 로그와 다수의 오래된 로그 파일
• /tmp, /var/tmp: 정리되지 않은 임시 파일
• /var/lib/docker, /var/lib/containerd: 컨테이너 레이어, 빌드 캐시, 컨테이너 로그
• 웹 애플리케이션의 캐시·세션·썸네일·업로드 임시 경로
• 메일 서버의 큐 또는 실패한 배달 메시지 경로
• 백업 프로그램이 생성한 증분 메타데이터나 작은 조각 파일

원인별 안전한 정리 방법

1. 오래된 캐시·세션 파일을 검토한 뒤 삭제

먼저 삭제 후보를 출력합니다. 아래 예시는 30일보다 오래된 일반 파일을 최대 100개까지만 보여줍니다.

sudo find /path/to/cache -xdev -type f -mtime +30 -print 2>/dev/null | head -n 100

경로와 파일의 용도를 확인하고 삭제해도 문제가 없는 파일만 포함되어 있다면 다음 명령으로 정리합니다.

sudo find /path/to/cache -xdev -type f -mtime +30 -delete

파일 삭제 후 비어 있는 하위 디렉터리까지 정리하려면 다음 명령을 별도로 실행합니다.

sudo find /path/to/cache -xdev -depth -mindepth 1 -type d -empty -delete

2. 시스템 임시 파일 정리

Ubuntu의 systemd-tmpfiles는 tmpfiles.d 정책에 설정된 보존 기간을 기준으로 임시 파일을 정리합니다. /tmp/*를 무조건 삭제하는 것보다 운영체제의 정리 정책을 사용하는 편이 안전합니다.

sudo systemd-tmpfiles --clean

정리 대상은 시스템과 패키지의 tmpfiles.d 설정에 따라 달라집니다. 실행 후 df -iT로 inode가 실제로 확보되었는지 확인합니다.

3. systemd journal 파일 정리

journal 파일이 과도하게 누적된 경우 현재 사용량을 확인한 뒤, 활성 journal을 회전하고 오래된 보관 파일을 정리할 수 있습니다.

journalctl --disk-usage
sudo journalctl --rotate --vacuum-time=14d

--vacuum-time=14d는 14일보다 오래된 보관 journal 파일을 제거합니다. 장애 분석에 필요한 로그 보존 정책이 있다면 기간을 임의로 줄이지 말고 운영 정책에 맞게 조정하십시오.

4. Docker가 많은 inode를 사용하는 경우

Docker를 사용하는 서버에서는 이미지 레이어, 중지된 컨테이너, 빌드 캐시와 컨테이너 로그가 /var/lib/docker 아래에 많은 파일을 만들 수 있습니다. 먼저 Docker 자체 명령으로 사용 현황을 확인합니다.

sudo docker system df -v

사용하지 않는 중지 컨테이너, 네트워크, dangling 이미지와 빌드 캐시를 확인한 뒤 정리하려면 다음 명령을 실행합니다. 이 명령은 삭제 내용을 보여주고 확인을 요청합니다.

sudo docker system prune

5. 삭제했는데 inode가 줄지 않는 경우

프로세스가 파일을 연 상태에서 해당 파일이 삭제되면 디렉터리에서는 보이지 않지만, 프로세스가 파일 핸들을 닫을 때까지 inode와 디스크 블록이 계속 사용될 수 있습니다. lsof가 설치되어 있다면 다음 명령으로 링크가 끊어진 열린 파일을 확인합니다.

sudo lsof +L1

출력에서 COMMAND, PID, NAME을 확인하고 해당 프로세스를 관리하는 서비스를 찾습니다. 서비스 중단 영향이 없는 유지보수 시간에 정상적인 재시작으로 파일 핸들을 해제합니다.

sudo systemctl status SERVICE_NAME
sudo systemctl restart SERVICE_NAME

SERVICE_NAME은 실제 서비스명으로 변경합니다. 원인을 확인하지 않은 채 프로세스를 강제 종료하면 데이터 손상이나 서비스 장애가 발생할 수 있으므로 kill -9부터 사용하지 마십시오.

해결 여부 확인

1. inode 여유 공간 재확인

df -iT

IFree 값이 증가하고 IUse%가 100% 아래로 내려갔는지 확인합니다. 응급 복구 직후에는 최소한 서비스가 새 파일을 생성할 수 있을 정도로 inode를 확보해야 하며, 이후 원인 디렉터리를 추가로 정리해야 합니다.

2. 파일 생성 테스트

문제가 발생했던 파일시스템에서 임시 파일을 생성하고 삭제해 파일 생성이 정상적으로 동작하는지 확인합니다. 다음 예시는 /var/tmp가 문제 파일시스템에 포함된 경우에만 사용합니다.

TEST_FILE=$(mktemp /var/tmp/inode-test.XXXXXX)
ls -l "$TEST_FILE"
rm -f "$TEST_FILE"

오류 없이 임시 파일이 생성되고 삭제되면 기본적인 inode 할당은 정상입니다. mktemp가 계속 실패한다면 다른 마운트 지점을 테스트하지 말고 해당 파일시스템의 inode 사용률과 읽기 전용 상태를 다시 확인합니다.

3. 관련 서비스 상태 확인

inode 부족으로 중단되었던 서비스의 상태와 최근 로그를 확인합니다.

sudo systemctl status SERVICE_NAME --no-pager
sudo journalctl -u SERVICE_NAME -n 100 --no-pager

오류 로그에 No space left on device가 더 이상 나타나지 않고 서비스 상태가 active인지 확인합니다.

반복되는 inode 부족 문제의 근본 해결

방법 1. 파일 생성 원인과 보존 정책 수정

가장 먼저 애플리케이션이 소형 파일을 무제한으로 생성하는 원인을 수정해야 합니다. 단순히 파일을 삭제해도 동일한 서비스가 계속 파일을 만들면 inode는 다시 소진됩니다.

• 로그 로테이션과 보존 기간을 설정합니다.
• 세션·캐시·임시 파일의 만료 정책을 활성화합니다.
• 메일 큐 또는 작업 큐가 실패 파일을 무제한 재생성하지 않는지 확인합니다.
• 수백만 개 파일을 한 디렉터리에 저장하지 말고 해시 기반 하위 디렉터리 또는 데이터베이스·오브젝트 스토리지 사용을 검토합니다.
• Docker 컨테이너 로그 크기와 파일 개수 제한을 설정합니다.

방법 2. ext4 파일시스템 확장

ext4는 파일시스템을 확장할 때 기존 bytes-per-inode 비율을 유지하도록 inode 수가 함께 증가할 수 있습니다. LVM 볼륨 그룹에 여유 공간이 있다면 논리 볼륨과 파일시스템을 함께 확장하는 방법을 검토할 수 있습니다.

먼저 LVM 구성과 남은 공간을 확인합니다.

sudo pvs
sudo vgs
sudo lvs

볼륨 그룹에 충분한 여유 공간이 있고 대상이 ext4임을 확인한 경우, 다음 예시처럼 논리 볼륨을 확장할 수 있습니다. /dev/VG_NAME/LV_NAME과 크기는 실제 환경에 맞게 변경합니다.

sudo lvextend -L +20G -r /dev/VG_NAME/LV_NAME

기반 장치 또는 파티션이 이미 확장된 ext4 파일시스템이라면 다음 형식으로 남은 공간까지 확장할 수 있습니다.

sudo resize2fs /dev/DEVICE

/dev/DEVICE는 실제 ext4 장치로 변경합니다. resize2fs는 파티션 자체를 확장하지 않으므로, 기반 장치가 먼저 커져 있어야 합니다.

방법 3. 더 많은 inode를 갖도록 ext4 파일시스템 재생성

ext4의 bytes-per-inode 비율은 파일시스템 생성 후 직접 변경할 수 없습니다. 현재 크기를 유지하면서 inode 밀도를 크게 높여야 한다면 데이터를 백업하고 파일시스템을 새로 생성한 뒤 복원해야 합니다.

먼저 -n 옵션으로 실제 포맷 없이 예상 구성을 확인할 수 있습니다. 다음 예시는 4,096바이트당 하나의 inode를 생성하는 구성입니다.

sudo mkfs.ext4 -n -i 4096 /dev/DEVICE

백업 검증, 서비스 중지, 마운트 해제와 장치 확인을 모두 마친 뒤 실제로 재생성할 때 사용하는 형식은 다음과 같습니다.

sudo mkfs.ext4 -i 4096 /dev/DEVICE

inode를 많이 만들수록 inode 테이블이 차지하는 공간이 증가하여 실제 데이터 저장 공간이 줄어듭니다. 예상 평균 파일 크기와 최대 파일 수를 기준으로 적절한 비율을 계산하고, 재생성 후 새 UUID에 맞게 /etc/fstab을 확인한 뒤 데이터를 복원해야 합니다.

자주 발생하는 오류와 해결 방법

원상복구 및 사고 대응

inode 정리 과정에서 삭제한 파일은 일반적인 설정 변경처럼 즉시 원상복구할 수 없습니다. 삭제 전 백업이 원상복구 수단이므로, 잘못된 파일을 삭제했다면 추가 쓰기 작업을 최소화하고 다음 순서로 대응합니다.

1. 삭제된 파일을 계속 생성하거나 사용하는 관련 서비스를 중지합니다.
2. 백업 또는 스냅샷에서 삭제된 경로를 별도 위치로 먼저 복원합니다.
3. 소유자, 그룹, 권한과 SELinux·AppArmor 관련 설정이 필요한지 확인합니다.
4. 서비스 설정 검사 기능이 있다면 문법 검사를 수행합니다.
5. 서비스를 시작한 뒤 로그와 기능을 확인합니다.

Docker 정리로 제거된 중지 컨테이너와 이미지는 배포 정의 파일, 이미지 저장소와 백업을 이용해 다시 생성해야 합니다. ext4 파일시스템을 재생성한 경우에는 반드시 전체 백업에서 데이터를 복원하고 새 UUID, 마운트 옵션과 /etc/fstab을 확인해야 합니다.

재발 방지 방법

inode 사용률 모니터링

inode 사용률은 일반 디스크 사용률과 별도로 모니터링해야 합니다. 다음 명령은 inode 사용률이 80% 이상인 파일시스템만 표시합니다.

df -Pi | awk 'NR > 1 {usage=$5; gsub("%", "", usage); if (usage >= 80) print}'

운영 환경에서는 모니터링 시스템에서 inode 사용률 80%에 경고, 90% 이상에 긴급 알림을 설정하고 증가 추세를 함께 확인하는 것이 좋습니다.

운영 정책 점검 항목

• 애플리케이션 로그와 systemd journal 보존 기간을 정기적으로 검토합니다.
• 세션·캐시·업로드 임시 파일에 자동 만료 정책을 적용합니다.
• 컨테이너 이미지, 빌드 캐시와 로그 정리 일정을 운영 정책에 포함합니다.
• 파일 수가 빠르게 증가하는 경로를 별도 파일시스템으로 분리합니다.
• 수많은 소형 파일을 저장하는 용도라면 파일시스템 생성 시 inode 비율을 사전에 설계합니다.
• 정리 자동화는 삭제 경로, 최소 보존 기간, 제외 규칙과 실행 로그를 반드시 포함합니다.

관련 지구 IDC 기술자료

• Ubuntu 시스템 모니터링 도구로 서버 상태 점검하기
• 지구 IDC 기술자료 전체 보기

공식 참고자료

자주 묻는 질문

디스크 용량이 남아 있는데 왜 파일을 만들 수 없나요?

새 파일과 디렉터리는 저장 공간뿐 아니라 새로운 inode도 필요합니다. 파일시스템의 inode가 모두 사용되면 저장 용량이 남아 있어도 새 파일을 만들 수 없으며 No space left on device 오류가 발생할 수 있습니다.

tune2fs로 기존 ext4 파일시스템의 inode 수를 늘릴 수 있나요?

기존 ext4 파일시스템의 bytes-per-inode 비율을 tune2fs로 변경할 수는 없습니다. 기반 장치와 파일시스템을 확장하여 inode 수를 비례해서 늘리거나, 데이터를 백업한 뒤 더 낮은 bytes-per-inode 값으로 파일시스템을 재생성해야 합니다.

inode가 100%일 때 rm -rf /tmp/*를 실행해도 되나요?

권장하지 않습니다. 실행 중인 서비스가 사용하는 소켓, 잠금 파일 또는 임시 데이터를 삭제할 수 있습니다. 먼저 inode를 많이 사용하는 정확한 경로를 확인하고, Ubuntu의 systemd-tmpfiles --clean 또는 애플리케이션의 공식 정리 기능을 우선 사용하십시오.

디스크 용량을 늘리면 inode 부족도 해결되나요?

ext4 파일시스템 자체를 확장하면 기존 inode 비율을 유지하면서 inode 수가 증가할 수 있습니다. 단순히 새 디스크를 서버에 추가하기만 해서는 기존 파일시스템의 inode가 늘지 않으므로, 문제 경로를 새 파일시스템으로 이동하거나 기존 파일시스템을 실제로 확장해야 합니다.

inode 사용률은 어느 수준부터 관리해야 하나요?

파일 생성 속도에 따라 다르지만, 일반적으로 80% 이상부터 증가 원인을 점검하고 90% 이상에서는 긴급 정리와 용량 계획을 준비하는 것이 안전합니다. 현재 사용률뿐 아니라 하루 또는 일주일 단위 증가 속도를 함께 모니터링해야 합니다.