Linux 디스크 full vs inode full 해결 순서 | 용량·아이노드 트러블슈팅

들어가며

Linux 서버에서 “디스크가 찼다”는 알림은 흔하지만, 원인은 블록 용량 100%와 inode 고갈 두 가지로 갈립니다. Linux 서버 disk inode full 문제를 같은 방법으로만 접근하면 시간만 쓰고 해결이 늦어집니다. 먼저 어떤 쪽이 찼는지 구분하고, 그다음 어디 경로가 비정상인지 좁혀야 합니다.

이 글은 2026년 기준 일반적인 ext4/xfs 환경을 전제로, 읽기 전용 금지·서비스 중단을 최소화하는 순서를 정리합니다. 클라우드 VM·온프레미스·컨테이너 호스트 모두 공통으로 적용할 수 있습니다. Docker·Kubernetes로 쌓인 레이어·로그가 원인일 때는 Docker Compose·Kubernetes(minikube)·Nginx 운영 맥락과 함께 보시고, DB·캐시 데이터 디렉터리 용량은 Node.js DB 연동·C++ DB 연동·PostgreSQL vs MySQL·Redis 캐싱 스택과 연결해 점검하면 원인 추적이 빨라집니다.

왜 이 구분이 운영에 필요한가요?

모니터링 알람은 보통 “디스크” 한 가지로만 울리는 경우가 많습니다. 블록과 inode는 서로 다른 자원이라, 한쪽만 비우고 끝내면 파일 생성 실패나 로그 미기록이 계속될 수 있습니다. 특히 컨테이너 호스트에서는 이미지·레이어·빌드 캐시가 블록과 inode를 동시에 압박하는 경우가 있어, 원인 유형을 먼저 나누는 습관이 장애 시간을 줄입니다.

프로덕션에서 특히 주의할 점

• truncate·강제 삭제는 애플리케이션·감사 요구와 충돌할 수 있으므로, 운영 절차(변경 관리·백업) 없이 실행하지 않습니다.
• **docker system prune**은 편리하지만 필요한 이미지까지 지울 수 있어, 보존 목록·실행 주기를 팀 합의로 둡니다.
• inode 알람은 df -h만 보던 습관으로는 놓치기 쉬우므로, inode 잔여율을 메트릭에 포함하는 것을 권장합니다.

이 글을 읽으면

• df와 df -i로 용량 문제와 inode 문제를 구분할 수 있습니다
• 로그·캐시·Node node_modules·세션 파일 등 흔한 원인별 점검 순서를 알 수 있습니다
• 삭제 후에도 용량이 안 돌아오는 경우의 조치를 할 수 있습니다

---

목차

1. 개념 설명
2. 실전 구현
3. 고급 활용
4. 성능·비교
5. 실무 사례
6. 트러블슈팅
7. 마무리

---

개념 설명

블록 용량 vs inode

구분	의미	대표 증상
블록	파일 데이터가 차지하는 저장 공간	대용량 로그, 덤프, 미디어
inode	파일·폴더 메타데이터 슬롯	작은 파일이 수백만 개

df -h는 블록 사용률, df -ih는 inode 사용률을 보여 줍니다. Linux 서버 disk inode full은 후자가 100%에 가깝고, df -h는 여유가 있는 모순적인 상황이 자주 나옵니다.

왜 구분이 중요한가

• 블록만 정리하고 inode는 그대로면 여전히 파일 생성 실패
• 반대로 inode만 보고 큰 파일을 지우려 하면 원인 경로를 놓침

---

실전 구현

1단계: 상태 구분 (항상 여기서 시작)

df -h
df -ih

• df -h: 사람이 읽기 쉬운 단위(-h)로 파일 시스템별 블록 사용량과 마운트 지점을 표시합니다.

• df -ih: 동일 마운트에 대해 inode 사용 개수·총량·사용률을 사람이 읽기 쉬운 단위(-h)로 표시합니다. “용량은 남는데 파일을 못 만든다”면 이 출력을 확인합니다.

• 블록 100% 근접 → 대용량 파일·로그·코어 덤프 쪽 의심

• inode 100% 근접 → 소량 파일 대량 생성(캐시·메일 큐·세션·빌드 산출물) 의심

2단계: 어느 마운트인지 확인

df -h /
df -ih /var

문제 파티션을 정한 뒤, 그 아래에서만 작업합니다.

3단계: 블록 full일 때 — 큰 디렉터리 찾기

sudo du -xh / --max-depth=2 2>/dev/null | sort -h | tail -20

/var/log, /var/lib/docker, 애플리케이션 logs, DB 데이터 디렉터리를 우선 확인합니다.

안전한 예시(로그 로테이션 전 임시):

# 압축·아카이브 가능한 오래된 로그만 (정책에 맞게)
sudo truncate -s 0 /var/log/very_large_app.log   # 서비스 중단 주의—운영 절차 따름

실무에서는 logrotate 설정을 수정하는 것이 근본 대책입니다.

4단계: inode full일 때 — inode 많이 쓰는 경로

소량 파일이 많은 디렉터리를 찾습니다.

sudo find /var -xdev -type f | head
# 특정 상위만 의심될 때
sudo find /var/lib/docker -xdev -type f 2>/dev/null | wc -l

흔한 원인

• 캐시 디렉터리에 파일이 무한 증가
• 메일 스풀(/var/spool)
• 세션·임시 파일 미정리
• Node, PHP 등의 node_modules·캐시가 한 파티션에 몰림

정리 전 프로세스가 쓰는지 확인하고, 가능하면 서비스 중지 → 정리 → 시작 순서를 문서화합니다.

5단계: Docker 환경 (해당 시)

비유로 이해하기: 이미지는 요리 레시피, 실행 중인 컨테이너는 그 레시피로 만든 도시락에 가깝습니다. 레시피와 도시락이 쌓이면 호스트 디스크(블록·inode)를 함께 씁니다.

docker system df
sudo du -sh /var/lib/docker/*

• docker system df: 이미지·컨테이너·로컬 볼륨·빌드 캐시가 각각 얼마나 디스크를 쓰는지 요약합니다.
• **du -sh 경로*: 해당 경로 아래 디렉터리별 실사용량**을 빠르게 보려는 용도입니다(-s합계,-h` 단위).

이미지·빌드 캐시·중지 컨테이너는 정책에 따라 docker system prune 등으로 줄일 수 있습니다. 프로덕션은 유지 필요 이미지를 명시하고 실행합니다.

6단계: 삭제했는데 df가 안 줄어드는 경우

다른 프로세스가 삭제된 파일을 열어둔 경우입니다.

sudo lsof +L1
# 또는
sudo lsof /path/to/deleted

• lsof +L1: 링크 수가 0인 열린 파일을 나열합니다. 삭제했지만 프로세스가 열고 있으면 이 목록에 남습니다.
• lsof 경로: 해당 경로를 열고 있는 프로세스를 좁힐 때 사용합니다.

해당 데몬 재시작(또는 시그널) 후 공간이 회복되는지 확인합니다.

---

고급 활용

• xfs_quota / project quota: 멀티 테넌트 경로별 상한
• inotify 한계: fs.inotify.max_user_watches 부족은 inode와 별개지만, 빌드 워처 오류와 함께 점검
• 모니터링: Prometheus node_filesystem_*, inode는 node_filesystem_files_free 등으로 알람

---

성능·비교

상황	블록 압박	inode 압박
대용량 DB 덤프	◎	△
수백만 개 0바이트·작은 파일	△	◎
컨테이너 이미지 누적	◎	경우에 따라 ◎

둘 다 df 두 종류로 먼저 구분하는 것이 가장 빠릅니다.

---

실무 사례

• CI 러너: 워크스페이스에 작은 산출물이 쌓여 inode 고갈 → 주기적 정리 잡
• 웹 서버: 액세스 로그가 로테이션 없이 단일 파일로 수십 GB → logrotate + 압축
• 컨테이너 호스트: 오래된 이미지·빌드 캐시로 /var/lib/docker 블록 점유

---

트러블슈팅

증상	조치
No space left on device인데 df -h는 여유	inode 확인(df -i), 소량 파일 경로 검색
로그를 비웠는데 용량 동일	truncate vs 삭제, lsof로 열린 파일 확인
/tmp만 찼다	재부팅 시 비우는 설정인지, 앱이 /tmp에 무한 생성하는지
DB “디스크 full”	데이터 디렉터리 파티션과 로그 파티션이 분리돼 있는지 확인

흔한 실수와 해결

실수	왜 문제인가	해결 방향
rm만 하고 프로세스를 안 봄	삭제된 파일이 열려 있으면 블록이 안 돌아옵니다	lsof로 확인 후 서비스 재시작 등
inode 없는 줄 알고 큰 파일만 지움	inode 한도는 그대로라 새 파일 생성 실패가 계속됩니다	df -ih 후 소량 다량 파일 경로부터 정리
프로덕션에서 무분별 docker system prune -a	필요한 이미지까지 삭제되어 재배포 지연	태그·보존 정책·스크립트로 범위 제한
알람을 용량(블록)만 설정	inode 고갈을 늦게 발견합니다	inode·노드 메트릭을 동시 모니터링

---

마무리

Linux 서버 disk inode full과 블록 full은 증상은 비슷하지만 처음에 실행하는 명령이 다릅니다. df -h와 df -ih로 구분한 뒤, du·find로 경로를 좁히고, 삭제 후에도 공간이 복구되지 않으면 열린 파일을 의심해 보시기 바랍니다. SSH·원격 운영 흐름은 SSH 가이드와 함께 두시면 장애 대응이 한결 빨라집니다.