서버 운영 중 No space left on device 에러가 발생해 디스크 용량을 확인(df -h)했으나, 여유 공간이 충분한 경우가 있다.
이 현상은 물리적 용량 부족이 아니라 메타데이터(Inode) 고갈 또는 삭제됐지만 열려 있는 파일(좀비 파일) 문제일 가능성이 매우 높다.
: 이 글은 Ext4 파일 시스템을 기준으로 한다

---

증상 (The Paradox) #

Error Log #

cp: cannot create regular file 'backup.tar': No space left on device
Error: ENOSPC: no space left on device, write

Disk Check (df -h) #

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       100G   40G   60G  40% /

상황
디스크는 60GB나 남았는데, 시스템은 공간이 없다고 판단한다.

---

원인 1: Inode 고갈 (가장 흔한 원인) #

파일 시스템은 **용량뿐 아니라 파일 개수(Inode)**에도 한계가 있다.
용량이 남아 있어도 Inode가 소진되면 파일 생성은 불가능하다.

확인 방법 #

df -i

Filesystem       Inodes   IUsed    IFree IUse% Mounted on
/dev/sda1       6553600 6553600        0  100% /

IUse%가 100%라면 원인은 Inode 고갈이다.

범인 색출 (파일 폭증 위치 찾기) #

# 루트 기준 디렉토리별 파일 개수 집계 (시간 소요)
find / -xdev -type f 2>/dev/null | cut -d "/" -f 2 | sort | uniq -c | sort -nrl

# 현재 위치 하위 디렉토리별 파일 개수
for i in *; do echo -n "$i: "; find "$i" | wc -l; done

자주 문제 되는 경로:

• /var/spool/postfix
• /var/lib/php/sessions
• /var/log
• /usr/src/linux-headers

왜 이 디렉토리가 범인인가? (Why) #

• 용량이 아니라 ‘쪽수’ 싸움 Inode 에러(No space)는 디스크의 **무게(용량)**가 아니라 **주차 공간(슬롯 개수)**이 꽉 찼다는 뜻이다.
• 1파일 = 1Inode 아무리 작은 0바이트 파일이라도 Inode 1개를 무조건 잡아먹는다.
• 결론 전체 Inode 개수(df -i의 Total) 대비 해당 디렉토리가 과반수(예: 80~90%)를 점유하고 있다면, 파일 용량과 관계없이 그 디렉토리가 시스템 마비의 직접적인 원인이다.

삭제 전 주의사항 (Caution) #

파일이 많다고 무조건 지워도 되는 ‘쓰레기’는 아니다. 반드시 파일의 정체를 확인해야 한다.

• 지워도 되는 것 (Garbage/Cache):
  • sess_... (PHP 세션), postfix/defer (메일 스풀), 임시 캐시 파일.
  • 오래된 날짜(mtime)의 파일들이 쌓여 있다면 삭제 대상이다.
• 지우면 안 되는 것 (System/Data):
  • /var/lib/docker/overlay2: 절대 수동 삭제 금지. 컨테이너 시스템이 파괴된다. (docker prune 사용)
  • 서비스 데이터: 썸네일 이미지, 실제 적재 중인 로그, DB 파일 등.

Tip: 무턱대고 rm부터 날리지 말고, ls -lh | head로 파일 내용과 생성 날짜를 먼저 확인

원인 2: 삭제됐지만 열려 있는 파일 (Deleted but Open) #

로그 파일을 rm으로 삭제했지만, 실행 중인 프로세스가 해당 파일을 계속 잡고 있는 경우다.
이 경우 df -h에는 반영되지 않지만 실제 디스크 공간은 점유 중이다.

확인 방법 #

lsof | grep deleted

COMMAND   PID   USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
java      1234  root   1w   REG  8,1    50G      101  /var/log/app.log (deleted)

의미
java 프로세스가 이미 삭제된 로그 파일을 잡고 50GB를 점유 중.

해결 방법 #

• 가장 확실한 방법: 프로세스 재시작

systemctl restart <service_name>

• 재시작이 불가한 경우 (임시 조치)

cp /dev/null /proc/1234/fd/1

---

원인 3: Docker / OverlayFS 이슈 #

컨테이너 환경에서 자주 발생한다.
Docker의 overlay2 파일 시스템이나 컨테이너 로그가 정리되지 않으면
호스트 df -h는 정상인데 컨테이너 내부에서 ENOSPC가 발생한다.

점검 및 정리 #

# 중지된 컨테이너, 미사용 이미지/네트워크 정리
docker system prune -a

# 컨테이너 로그 용량 확인
du -h --max-depth=1 /var/lib/docker/containers

---

핵심 요약 #

• No space left on device인데 df -h가 정상이면 용량부터 의심하지 마라
• 1순위: df -i로 Inode 고갈 여부 확인
• Inode가 정상이면 lsof | grep deleted로 좀비 파일 확인
• Docker / K8s 환경이라면 overlay2 및 컨테이너 로그 정리 필요

이 순서만 지켜도 불필요한 디스크 증설과 애플리케이션 디버깅을 피할 수 있다.

🛠 마지막 수정일: 2025.12.23