Ubuntu에서 저장 공간이 남아 있는데 No space left on device가 뜨면 큰 파일부터 지우지 마세요. 파일 내용의 용량과 inode 여유는 다른 항목입니다. inode는 파일의 메타데이터를 담습니다. 이 글은 새 파일 생성 실패와 inode 소진 여부를 구분하는 조회 절차이며, 일반 디스크 청소나 삭제 안내가 아닙니다.
확인일: 2026-10-06 · Ubuntu 24.04 LTS Noble 공식 manpage 기준. 실제 서버에서 장애를 재현한 후기는 아닙니다.
빠른 결론
① 실패한 경로에서 df -h와 df -i를 함께 봅니다.
② 용량은 남고 IFree가 0이면 inode 소진을 우선 의심합니다.
③ 작은 범위만 집계하고, 삭제 여부는 소유 서비스와 보존 정책을 확인한 뒤 결정합니다.
용량과 inode를 구분하는 표
| 조회 | 확인 값 | 판단 |
|---|---|---|
df -h 경로 |
Avail, Use% | 파일 내용 등을 저장할 블록 여유 |
df -i 경로 |
IFree, IUse% | 블록 사용량 대신 inode 정보 |
df -T 경로 |
Type, Mounted on | 파일시스템 형식과 대상 위치 |
| 범위를 제한한 find | 디렉터리 항목 수 | 파일이 많이 생긴 후보를 좁히는 참고값 |
안전한 점검 순서
- 실패한 위치를 먼저 확인합니다. 파일 생성이 실패한 디렉터리 또는 존재하는 부모 경로를 찾으세요. 아래
/path/to/app-cache는 예시이므로 실제 확인한 앱 디렉터리로 바꿉니다. 루트 전체나 다른 디스크를 측정하면 장애 경로와 무관한 결과를 볼 수 있습니다.df -h /path/to/app-cache df -i /path/to/app-cache df -T /path/to/app-cache - 같은 파일시스템의 두 결과를 비교합니다. Avail이 남아도 IFree가 0이면 새 inode를 할당할 여유가 없는 상태를 의심합니다. IUse%만 보지 말고 IFree도 함께 읽으세요. 두 값이 모두 부족할 수도 있습니다. 공식 open 매뉴얼은 새 파일을 만들 공간이 없을 때 ENOSPC가 발생한다고 설명하므로, 오류 문구만으로 inode 문제를 단정하지 않습니다.
- 앱 소유의 작은 디렉터리부터 항목 수를 봅니다. 먼저 바로 아래 항목만 세고, 필요할 때 같은 경로에서 깊이를 3으로 늘립니다. 기본 find는 심볼릭 링크를 따라가지 않습니다.
find /path/to/app-cache -xdev -mindepth 1 -maxdepth 1 -printf 'x' | wc -c find /path/to/app-cache -xdev -mindepth 1 -maxdepth 3 -printf 'x' | wc -c-xdev는 다른 파일시스템으로 내려가지 않게 하고,-maxdepth는 탐색 깊이를 제한합니다. 항목마다 문자 x 하나를 출력해 바이트를 세므로 파일명에 줄바꿈이 있어도 그 줄 수를 잘못 세지 않습니다. 이 숫자는 지정 깊이 안의 파일·디렉터리 등 항목 수이며 전체 inode 사용량과 같지 않습니다. - 많은 후보를 더 작은 경로로 좁힙니다. 위 두 명령만으로 하위 폴더별 순위가 나오지는 않습니다. 확인한 후보 폴더를 하나씩 지정해 같은 깊이 조건으로 비교하세요. 권한 오류를 숨기지 말고, 오류가 있으면 집계가 일부만 포함됐을 수 있음을 기록합니다. 읽기 전용 탐색도 항목이 많으면 부하가 생기므로 운영 서버에서 전역 검색부터 시작하지 않습니다.
- 정리 대신 발생 주체를 기록합니다. 후보 경로, 파일 증가 시각, 관련 앱과 보존 기준을 담당자에게 전달합니다. 승인된 서비스 절차로 조치한 뒤 같은 경로에서 df 두 명령을 다시 비교하세요. 실제 원인과 삭제 가능한 파일은 이 조회만으로 확인되지 않습니다.
주의사항
DB 데이터, 컨테이너 저장소, 시스템 디렉터리는 파일 수가 많다는 이유로 건드리지 마세요. 이 글에는 삭제·서비스 재시작 명령이 없습니다. 하드 링크 등으로 항목 수와 고유 inode 수는 다를 수 있으며, 깊이 제한 밖의 파일도 집계되지 않습니다. Permission denied가 뜬 숫자를 전체 결과로 취급하지 말고 필요한 권한은 관리자와 확인하세요.
아직 해결되지 않았다면
IFree가 충분하면 inode 소진은 미확인입니다. 실패한 앱이 실제로 쓰는 경로가 맞는지, 컨테이너 안과 호스트의 대상이 같은지, 발생 시각의 오류가 파일 생성인지 쓰기인지부터 다시 확인하세요. quota·파일시스템별 제약·다른 저장 위치는 별도 점검 대상이며 여기서는 원인을 검증하지 않았습니다. 일반 블록 용량 문제는 Linux 디스크 용량 점검·정리, 실패 시각의 서비스 로그는 Ubuntu 서비스 실행 실패 로그 찾기를 참고하세요.
FAQ
Q1. 용량이 남아도 파일을 못 만들 수 있나요?
네. 블록 여유와 inode 여유를 나눠 봐야 합니다. 다만 오류 메시지만으로 inode 소진이라고 확정하지 마세요.
Q2. find 집계가 df -i와 왜 다른가요?
find는 접근 가능한 경로의 항목을 지정 깊이까지만 셉니다. df는 해당 파일시스템의 inode 정보를 보여주므로 측정 범위가 다릅니다.
Q3. 파일 수가 가장 많은 폴더를 지우면 되나요?
아닙니다. 서비스 필수 데이터일 수 있습니다. 소유 앱·백업·보존 정책을 확인하고 공식 서비스 절차를 검토하세요.
댓글