파일을 저장하려는데 “No space left on device”가 나왔지만 디스크에는 여유가 남아 있습니다. 이때 큰 파일부터 지우면 원인을 놓칠 수 있습니다. 파일시스템에는 데이터를 담을 공간과 파일 정보를 관리할 자원이 따로 있기 때문입니다. 이 글은 GNU 도구를 사용하는 Linux 환경에서 두 자원을 구별하는 점검 순서를 설명합니다.
파일시스템에서 빈 공간과 inode는 서로 다른 객체
inode는 소유자·권한·시간 정보와 데이터 위치 등 파일의 메타데이터를 담는 구조입니다. 파일명은 디렉터리 항목에 기록되고 해당 inode와 연결됩니다. Linux 커널의 ext4 문서도 이 구분을 설명합니다.
새 파일이나 디렉터리를 만들려면 이를 위한 inode가 필요합니다. 따라서 작은 파일이 대량으로 쌓이면 데이터 용량을 많이 쓰지 않아도 사용 가능한 inode가 먼저 소진될 수 있습니다. Red Hat의 공개 문제 설명에는 ext2·ext3·ext4에서 디스크 여유가 있는데도 inode 부족으로 파일 생성이 실패하는 조건이 제시되어 있습니다.
다만 파일명 개수와 inode 사용량을 항상 같다고 보면 안 됩니다. 하드 링크는 여러 이름이 하나의 inode를 공유할 수 있고, 디렉터리 자체도 inode를 사용합니다. 파일 크기만으로 inode 부족 여부를 판단하기 어려운 이유입니다.
오류 경로에서 두 사용량을 교차 확인
서버 전체의 여유보다 먼저 확인할 것은 저장에 실패한 경로입니다. 아래 /var/app/data는 예시이며, 실제로 존재하는 대상 디렉터리로 바꿔 실행합니다. 새로 만들 파일이 아직 없다면 그 파일을 담을 상위 디렉터리를 지정합니다.
df -hT /var/app/data
df -i /var/app/dataGNU df 문서에 따르면 경로를 인수로 주면 그 경로가 속한 파일시스템을 조회합니다. 첫 명령은 용량과 파일시스템 종류를, 두 번째는 inode 사용량을 보여줍니다. 두 결과의 Filesystem과 Mounted on을 대조해 같은 대상을 보고 있는지 확인합니다.
| 관찰 결과 | 우선 판단 |
|---|---|
| 용량의 Avail이 부족하고 inode는 남아 있음 | 데이터 공간 부족부터 조사 |
| 용량은 남아 있으나 IFree가 0임 | 새 inode 할당 불가 여부를 우선 조사 |
| 두 자원 모두 여유가 있음 | 오류 문구와 다른 제한을 추가 확인 |
예를 들어 ext4에서 용량 Use%가 40%인데 inode IUse%가 100%, IFree가 0이라면 inode 소진을 우선 의심할 근거가 됩니다. 이는 설명을 위한 가정이며 실제 서버 측정값은 아닙니다. 반올림된 비율만 보지 말고 남은 개수인 IFree도 확인해야 합니다.
반대로 inode 값이 표시되지 않거나 파일시스템이 다르면 같은 기준을 기계적으로 적용하지 않습니다. 두 자원이 남아 있다면 사용자·프로젝트 할당량, 파일시스템별 메타데이터 제약 등을 별도로 살펴봅니다. 권한 거부나 읽기 전용 오류도 정확한 메시지에 따라 구분합니다.
용량이 큰 파일보다 작은 파일의 관리 필요
inode 부족이 확인되면 디렉터리별 사용량을 좁혀 봅니다. GNU du에서는 다음처럼 바이트 대신 inode 사용량을 집계할 수 있습니다. /var/app/data는 앞에서 확인한 파일시스템 안의 조사 대상 경로로 바꿉니다.
du --inodes -x --max-depth=1 /var/app/dataGNU du 문서에서 --inodes는 inode 기준 집계, -x는 다른 파일시스템으로의 탐색 제외, --max-depth=1은 출력 깊이 제한에 해당합니다. 값이 큰 하위 디렉터리를 다음 조사 대상으로 삼습니다. 출력 깊이를 제한해도 하위 트리 집계는 수행하므로 파일이 많으면 시간이 걸릴 수 있습니다.
권한 오류가 있으면 집계에서 빠진 영역이 있는지 확인해야 합니다. 또한 du는 접근 가능한 디렉터리 트리를 세는 도구이므로 파일시스템 전체 상태를 보여주는 df와 총계가 반드시 일치하지는 않습니다. 큰 값은 조사 우선순위이지 곧바로 삭제할 근거는 아닙니다.
가정 사례로 세션 파일, 캐시 조각, 작업별 임시 파일이 쌓인 상황을 생각할 수 있습니다. 보존기간과 사용 여부를 확인한 뒤 애플리케이션이 제공하는 정리 절차를 우선 검토합니다. 파일 내용만 비우면 inode는 남으므로, 용량을 줄이는 작업과 파일 수를 줄이는 작업도 구별해야 합니다.
정리 후에는 재발 조건까지 확인
정리 뒤 같은 경로에서 df -i를 다시 확인하고 애플리케이션의 정상 저장 절차로 파일 생성이 가능한지 점검합니다.
삭제한 파일을 프로세스가 계속 열고 있거나 다른 하드 링크가 남아 있으면 inode가 즉시 반환되지 않을 수 있습니다. 이때 재시작부터 하기보다 열린 파일과 링크 상태를 확인합니다.
재발 방지는 파일 생성 속도와 보존 방식을 함께 보는 작업입니다. 작은 파일을 계속 만드는 구조라면 만료 처리의 실행 여부, 실패 기록, 보관 정책을 점검하고 용량과 inode 여유를 각각 모니터링합니다. 증설이나 파일시스템 재구성은 종류와 구성에 맞춰 검토해야 하며, 저장장치 용량 증가만으로 해결된다고 단정할 수 없습니다.
결론
디스크 여유가 있는데 파일 생성이 실패하면 먼저 오류 경로에서 df -hT와 df -i를 비교합니다. inode 부족이 드러나면 du --inodes로 집중 구간을 찾고, 사용·보존 조건을 확인해 정리합니다. 이후 남은 inode와 실제 저장 동작을 함께 확인하면 용량 부족과 파일 수 증가에 따른 문제를 구별할 수 있습니다.