리눅스 서버 용량은 남았는데 파일 생성이 안 될 때 df -i로 inode 확인하는 법

리눅스 서버에서 df-h 용량은 남아 있는데 파일 생성이 안 될 때 df-i 명령어로 inode 부족 여부를 확인하는 방법을 설명하는 대표 이미지

리눅스 서버에서 df -h로 보면 디스크 용량은 아직 남아 있는데, 파일 생성이나 로그 기록이 안 되고 No space left on device 오류가 뜨는 경우가 있습니다. 이때 초보 운영자는 “용량이 남았는데 왜 공간이 없다고 하지?” 하고 당황하기 쉽지만, 실제 원인은 디스크 용량이 아니라 inode 부족일 수 있습니다. 이번 글에서는 서버 운영 중 용량은 남았는데 파일이 생성되지 않을 때 df -i 명령어로 inode 상태를 확인하고, 작은 파일이 많이 쌓인 경로를 안전하게 점검하는 순서를 정리합니다.

No space left on device가 항상 용량 부족은 아닙니다

No space left on device라는 문구만 보면 보통 디스크 용량이 꽉 찼다고 생각하기 쉽습니다.

예를 들어 이런 상황입니다.

 

touch test.txt

 

touch: cannot touch 'test.txt': No space left on device

 

이 메시지만 보면 “디스크가 꽉 찼나?” 하고 df -h부터 보게 됩니다.

 

df -h

 

예시입니다.

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        50G   30G   20G  60% /

 

그런데 이상하게도 용량은 20GB나 남아 있습니다.

이럴 때 바로 서버를 재기동하거나 파일을 무작정 삭제하기보다, inode 부족을 의심해야 합니다.

inode가 뭘까?

inode는 리눅스 파일시스템에서 파일 정보를 저장하는 번호표 같은 개념입니다.

파일 이름 자체보다, 파일의 실제 정보는 inode에 저장됩니다.

파일 권한
소유자
파일 크기
생성/수정 시간
데이터 위치 정보

 

쉽게 말하면 파일 하나를 만들 때마다 inode 하나가 필요합니다.

그래서 디스크 용량이 남아 있어도 inode가 다 차면 새 파일을 만들 수 없습니다.
종이 창고에 빈 공간은 남아 있는데, 파일을 꽂을 번호표가 다 떨어진 상황에 가깝습니다.

운영 서버에서는 큰 파일 몇 개보다 작은 파일 수십만 개, 수백만 개가 쌓일 때 inode 부족이 생길 수 있습니다.

가상의 운영 상황 예시

예를 들어 웹 애플리케이션 서버에서 아래와 같은 상황이 발생했다고 가정해보겠습니다.

[상황]
- 파일 업로드 실패 발생
- 애플리케이션 로그에 No space left on device 메시지 확인
- df -h 결과 / 파일시스템 사용률은 60%
- /tmp 아래 임시 업로드 파일이 계속 쌓이는 것으로 의심

 

이 상황에서 초보 운영자는 이렇게 생각할 수 있습니다.

용량은 남았는데 왜 파일 생성이 안 되지?
df -h가 60%면 디스크 문제는 아닌가?
그럼 서비스를 재시작해야 하나?

 

하지만 이때 바로 재기동으로 가기보다 df -i를 먼저 확인하는 것이 좋습니다.

1단계. df -h가 아니라 df -i도 확인하기

디스크 용량은 df -h로 확인합니다.

 

df -h

 

inode 사용량은 df -i로 확인합니다.

 

df -i

 

예시입니다.

Filesystem      Inodes  IUsed   IFree IUse% Mounted on
/dev/sda2      3276800 3276000    800  100% /

 

여기서 봐야 할 것은 IUse%입니다.

IUse% 100%

 

이렇게 보인다면 inode가 거의 다 찬 상태입니다.

즉, 디스크 용량은 남아 있어도 새 파일을 만들 inode가 부족한 상태일 수 있습니다.

df -h와 df -i 차이

둘은 보는 기준이 다릅니다.

df -h → 디스크 용량 사용률 확인
df -i → inode 사용률 확인

 

비교하면 이렇게 볼 수 있습니다.

 

df -h
df -i

 

예시입니다.

df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        50G   30G   20G  60% /

df -i
Filesystem      Inodes  IUsed   IFree IUse% Mounted on
/dev/sda2      3276800 3276000    800  100% /

 

이런 경우는 용량이 아니라 inode가 문제입니다.

운영 서버에서 디스크 이슈를 볼 때 df -h만 보면 반쪽만 보는 셈입니다.
용량은 남았는데 파일 생성이 안 된다면 df -i까지 같이 보는 습관이 필요합니다.

 

디스크 용량 문제는 df -h만 보면 놓치는 경우가 있습니다. 파일을 삭제했는데도 용량이 줄지 않거나 df와 du 결과가 다르게 보이는 상황은 아래 글에서 이어서 확인할 수 있습니다.

 

2026.05.02 - [리눅스] - 리눅스 서버 df -h 결과, Use%만 보면 안 되는 이유와 확인 순서

리눅스 서버 df -h 결과, Use%만 보면 안 되는 이유와 확인 순서

 

2단계. 어느 마운트 지점의 inode가 부족한지 확인하기

df -i 결과에서도 Mounted on을 꼭 같이 봐야 합니다.

 

df -i

 

예시입니다.

Filesystem      Inodes  IUsed   IFree   IUse% Mounted on
/dev/sda2      3276800 3276000     800   100% /
/dev/sdb1      6553600 1200000 5353600    19% /data

 

여기서는 / 파일시스템의 inode가 부족합니다.
/data는 문제가 아닙니다.

이 상태에서 /data를 아무리 정리해도 /의 inode 부족은 해결되지 않습니다.

먼저 어느 파일시스템의 inode가 부족한지 정확히 잡아야 합니다.

/       → OS 영역, 일부 로그, 임시파일 확인
/var    → 로그, 캐시, 스풀, 서비스 데이터 확인
/tmp    → 임시파일 확인
/data   → 애플리케이션 데이터 확인
/app    → 서비스 로그, 업로드 파일 확인

 

df -h와 마찬가지로 df -i도 숫자만 보지 말고 Mounted on을 함께 봐야 합니다.

3단계. 작은 파일이 많은 디렉터리 찾기

inode 부족은 보통 큰 파일 하나보다 작은 파일이 너무 많을 때 발생합니다.

자주 의심할 만한 경로는 이런 곳입니다.

/tmp
/var/tmp
/var/spool
/var/cache
/var/log
애플리케이션 임시 파일 경로
세션 파일 저장 경로
업로드 임시 경로
컨테이너 작업 디렉터리

 

먼저 문제 파일시스템 안에서 파일 개수가 많은 경로를 찾습니다.

루트 파일시스템이 문제라면 아래처럼 볼 수 있습니다.

 

for d in /*; do echo "$d"; find "$d" -xdev -type f 2>/dev/null | wc -l; done

 

다만 운영 서버에서는 / 전체를 훑는 작업이 부담이 될 수 있습니다.
가능하면 의심되는 경로부터 좁혀서 확인하는 것이 좋습니다.

예를 들어 /var가 의심된다면 아래처럼 확인합니다.

 

for d in /var/*; do echo "$d"; find "$d" -xdev -type f 2>/dev/null | wc -l; done

 

예시 결과입니다.

/var/cache
120000

/var/log
35000

/var/spool
900000

 

이 결과에서는 /var/spool 아래 파일 개수가 매우 많습니다.

이때 바로 삭제하지 말고, 먼저 왜 파일이 쌓였는지 확인해야 합니다.

메일 큐가 쌓였는지
작업 큐가 처리되지 않는지
배치 작업이 실패했는지
애플리케이션이 임시 파일을 남기는지
정리 정책이 없는지

 

파일 개수 확인은 삭제 대상 확정이 아니라 원인을 좁히는 단계입니다.

4단계. /tmp의 오래된 임시 파일 확인하기

작은 파일이 많이 쌓이는 대표 경로가 /tmp입니다.

하지만 /tmp라고 해서 바로 삭제하면 안 됩니다.
현재 실행 중인 서비스가 사용하는 임시파일, 소켓, 작업 파일이 있을 수 있습니다.

먼저 오래된 파일만 확인합니다.

 

find /tmp -xdev -type f -mtime +7 | head

 

개수만 확인할 수도 있습니다.

 

find /tmp -xdev -type f -mtime +7 | wc -l

 

예시입니다.

152340

 

7일 이상 된 임시파일이 15만 개 이상이라면 inode 부족 원인일 수 있습니다.

하지만 삭제 전에는 아래를 확인해야 합니다.

현재 서비스가 쓰는 파일인지
최근 수정 시간이 언제인지
삭제 정책이 있는지
배치나 애플리케이션이 임시 파일을 남기는지
동일한 파일이 계속 생성되고 있는지

/tmp 경로는 임시파일이 많이 쌓이는 대표적인 위치입니다. /tmp가 꽉 찼을 때 바로 삭제하지 않고 안전하게 확인하는 흐름은 아래 글에서 따로 정리해두면 좋습니다.

 

2026.07.11 - [리눅스] - 리눅스 서버 /tmp 용량 찼을 때 당황해서 바로 삭제하지 마세요 - 안전한 임시 파일 확인 및 조치 순서

리눅스 서버 /tmp 용량 찼을 때 당황해서 바로 삭제하지 마세요 - 안전한 임시 파일 확인 및 조치

 

5단계. 바로 rm -rf 하지 않기

inode가 부족하다고 바로 아래처럼 실행하는 것은 위험합니다.

 

rm -rf /tmp/*

 

운영 서버에서 /tmp에는 현재 실행 중인 서비스가 사용하는 소켓, 임시파일, 작업 파일이 있을 수 있습니다.

무작정 삭제하면 예상하지 못한 서비스 오류가 날 수 있습니다.

먼저 삭제 대상 파일을 목록으로 확인합니다.

 

find /tmp -xdev -type f -mtime +7 -print | head -n 20

 

문제가 없어 보이는 오래된 파일부터 조심스럽게 처리해야 합니다.

삭제가 필요하다면 한 번에 너무 많이 지우기보다 범위를 좁히는 것이 안전합니다.

 

find /tmp -xdev -type f -mtime +30 -delete

 

이 명령어도 운영 서버에서는 신중하게 사용해야 합니다.

실행 전에는 반드시 -delete 없이 대상 목록을 먼저 확인하는 습관이 좋습니다.

 

find /tmp -xdev -type f -mtime +30 -print | head

 

대상이 맞는지 확인한 뒤, 영향 범위를 판단하고 조치해야 합니다.

6단계. 파일 개수가 많은 하위 디렉터리 좁히기

특정 디렉터리 아래에 파일이 많다면 한 단계 더 내려가서 봅니다.

예를 들어 /var/spool이 의심된다면 아래처럼 확인합니다.

 

for d in /var/spool/*; do echo "$d"; find "$d" -xdev -type f 2>/dev/null | wc -l; done

 

또는 전체 파일 개수를 봅니다.

 

find /var/spool -xdev -type f | wc -l

 

파일이 너무 많으면 ls 명령어도 느려질 수 있습니다.

 

ls /var/spool/example

 

파일이 수십만 개 이상 있는 디렉터리에서는 ls가 오래 걸리거나 멈춘 것처럼 보일 수 있습니다.
이럴 때는 find와 wc -l로 조심스럽게 확인하는 편이 좋습니다.

7단계. 애플리케이션이 작은 파일을 계속 만들고 있는지 확인하기

inode 부족은 단순히 파일을 삭제하는 것으로 끝나지 않을 수 있습니다.
원인을 남겨두면 다시 찹니다.

예를 들어 이런 경우입니다.

세션 파일이 계속 쌓임
임시 업로드 파일이 정리되지 않음
캐시 파일이 무한 증가
작업 큐 파일이 처리되지 않음
로그가 파일 단위로 너무 잘게 쌓임
컨테이너 로그 또는 임시 파일 누적

 

최근 생성 파일을 확인해볼 수 있습니다.

 

find /tmp -xdev -type f -mmin -60 | head

 

또는 개수를 봅니다.

 

find /tmp -xdev -type f -mmin -60 | wc -l

 

최근 1시간 안에 파일이 매우 많이 만들어지고 있다면, 어떤 프로세스나 애플리케이션이 계속 파일을 생성하는지 확인해야 합니다.

이 경우는 “오래된 파일 정리”보다 “왜 계속 생성되는지”를 보는 것이 더 중요할 수 있습니다.

8단계. lsof로 사용 중인 파일 확인하기

삭제하려는 경로에 현재 사용 중인 파일이 있을 수 있습니다.

특정 경로를 사용 중인 프로세스를 볼 때는 lsof를 사용할 수 있습니다.

 

lsof +D /tmp 2>/dev/null | head

 

다만 lsof +D는 경로 전체를 훑기 때문에 파일이 매우 많은 디렉터리에서는 무거울 수 있습니다.
운영 서버에서는 범위를 좁혀서 쓰는 것이 좋습니다.

예를 들어 의심 경로가 /tmp/upload-cache라면 이렇게 좁혀서 봅니다.

 

lsof +D /tmp/upload-cache 2>/dev/null | head

 

deleted 파일도 함께 확인할 수 있습니다.

 

lsof | grep deleted

 

inode 부족 자체와 deleted 파일 문제는 다르지만, 디스크 이슈를 같이 보는 상황에서는 함께 확인해두면 좋습니다.

9단계. 로그 로테이션과 정리 정책 확인하기

inode 부족은 정리 정책이 없거나 제대로 동작하지 않을 때 자주 발생합니다.

로그라면 logrotate 설정을 확인합니다.

 

ls -l /etc/logrotate.d/

 

특정 애플리케이션 로그 정책이 있다면 확인합니다.

 

grep -R "/app/logs" /etc/logrotate.d/

 

임시 파일이라면 systemd-tmpfiles 정책을 볼 수 있습니다.

 

systemd-tmpfiles --cat-config | head

 

환경에 따라 이 명령어가 없거나 권한이 필요할 수 있습니다.

핵심은 “한 번 지우기”보다 왜 계속 쌓이는지를 보는 것입니다.
정리 정책이 없으면 파일을 지워도 며칠 뒤 같은 문제가 반복될 수 있습니다.

10단계. 운영자 보고 문장 예시

초보 운영자가 inode 부족을 발견했다면 이렇게 정리해서 공유하면 좋습니다.

[디스크 inode 부족 확인]

- 발생 시각: 2026-07-13 15:30
- 대상 서버: web-01
- 증상: 파일 생성 실패 및 No space left on device 오류 발생
- 확인 내용:
  1) df -h 결과 / 파일시스템 용량 사용률 60%
  2) df -i 결과 / 파일시스템 inode 사용률 100%
  3) /var/spool/example 하위 파일 개수 약 90만 개 확인
  4) 최근 1시간 내 생성 파일 다수 확인
- 추정 원인:
  애플리케이션 임시 파일 또는 작업 큐 파일 누적 가능성
- 조치 방향:
  사용 중 여부와 정리 정책 확인 후 오래된 파일부터 정리 검토

 

이렇게 쓰면 단순히 “용량이 이상합니다”보다 훨씬 명확합니다.

운영 보고에서는 아래 4가지를 함께 적으면 좋습니다.

df -h 기준 용량 상태
df -i 기준 inode 상태
파일 개수가 많은 경로
서비스 영향과 조치 방향

 

운영 서버에서 조심할 점

inode 부족 상황에서 아래 작업은 특히 조심해야 합니다.

 

rm -rf /tmp/*
rm -rf /var/*
find /tmp -type f -delete
reboot

 

이런 조치는 빠르게 보일 수 있지만, 사용 중인 파일을 지우거나 장애 원인 단서를 없앨 수 있습니다.

특히 /var 아래에는 로그뿐 아니라 서비스 데이터, 패키지 데이터, 스풀 데이터가 있을 수 있으므로 함부로 지우면 위험합니다.

운영 서버에서는 이렇게 확인하는 것이 안전합니다.

1. df -i 로 inode 부족 여부 확인
2. Mounted on 기준으로 파일시스템 확인
3. 파일 개수가 많은 경로 확인
4. 오래된 파일인지 확인
5. 사용 중인 파일인지 확인
6. 정리 정책 확인
7. 영향 범위 확인 후 삭제 또는 조치

 

디스크 용량 문제를 처음부터 순서대로 보고 싶다면 전체 점검 흐름도 함께 확인해두면 좋습니다. 아래 글에서는 디스크 사용률이 90%를 넘었을 때 바로 삭제하지 않고 확인하는 순서를 정리했습니다.

 

2026.05.02 - [리눅스] - 리눅스 서버 디스크 용량 90% 넘었을 때 바로 삭제하지 말고 확인하는 법

리눅스 서버 디스크 용량 90% 넘었을 때 바로 삭제하지 말고 확인하는 법

 

정리하면

df -h에서 용량이 남아 있어도 파일 생성이 안 될 수 있습니다.
이때는 inode 부족을 의심해야 합니다.

확인 명령어는 이것입니다.

 

df -i

 

그리고 확인 순서는 이렇게 잡으면 좋습니다.

1. df -h 로 용량 확인
2. df -i 로 inode 확인
3. IUse% 높은 파일시스템 확인
4. 파일 개수 많은 디렉터리 찾기
5. 오래된 임시 파일 확인
6. 사용 중인 파일 여부 확인
7. 정리 정책 확인
8. 영향 범위 확인 후 조치

 

 

inode 부족은 처음 보면 디스크 용량 문제처럼 보이지 않을 수 있습니다.

df -h에서는 용량이 남아 있는데도 파일 생성이 안 된다면, df -i로 inode 사용률을 함께 확인해야 합니다.

운영 서버에서는 파일을 지우는 것보다 먼저, 어떤 파일시스템에서 inode가 부족한지 확인하는 것이 중요합니다.  
그리고 작은 파일이 많이 쌓인 원인을 찾아야 같은 문제가 반복되는 것을 막을 수 있습니다.

용량이 남아 있어도 파일을 만들 수 없다면, inode를 확인하세요.

디스크 용량 문제를 전체 순서로 보고 싶다면 아래 글을 함께 보면 좋습니다.

https://opsnote.tistory.com/70

리눅스 서버 디스크 용량 문제 확인 순서 총정리

 

/tmp 용량이 찼을 때는 오래된 임시 파일인지, 현재 프로세스가 사용하는 파일인지, 정리 정책이 있는지 함께 확인해야 합니다.

https://opsnote.tistory.com/67

리눅스 서버 /tmp 용량이 찼을 때 바로 삭제하지 말고 확인하는 법