inode가 부족하면 디스크 공간이 남아도 파일을 만들 수 없는 이유

Linux 서버에서 디스크 사용량을 확인했을 때 여유 공간이 충분한데도 새로운 파일을 생성하지 못하는 상황이 발생할 수 있습니다. 디스크 용량이 부족하지 않은데 애플리케이션에서는 No space left on device 오류가 발생하고, 로그 기록이나 임시 파일 생성까지 실패하는 현상입니다.

이러한 문제는 디스크의 저장 공간이 아니라 파일을 관리하는 inode 자원이 고갈되었을 때 발생할 수 있습니다.

Linux 파일시스템은 파일의 실제 데이터를 저장하는 공간과 파일의 메타데이터를 관리하는 구조를 구분합니다. 따라서 디스크에 데이터 블록이 남아 있더라도 새로운 파일에 필요한 inode를 할당할 수 없다면 파일 생성이 실패할 수 있습니다.

이번 글에서는 Linux inode의 역할과 동작 원리, inode 부족으로 발생하는 서버 장애, 실제 inode 사용량을 분석하는 방법, 그리고 운영 환경에서 적용할 수 있는 해결 방법을 살펴보겠습니다.

inode 부족 문제가 발생하는 원인

일반적으로 서버의 디스크 공간을 확인할 때는 df -h 명령어를 사용합니다.

df -h

이 명령어는 파일시스템의 전체 용량, 사용량, 남은 공간을 보여줍니다.

예를 들어 다음과 같은 결과가 나타났다고 가정하겠습니다.

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

전체 디스크 용량은 100GB이며 사용 가능한 공간은 60GB입니다.

디스크 사용률이 40%에 불과하므로 일반적인 저장 공간 부족 문제는 아닌 것으로 판단할 수 있습니다.

하지만 실제 서버에서는 다음과 같은 오류가 발생할 수 있습니다.

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

이 오류는 반드시 디스크의 데이터 저장 공간이 부족하다는 의미는 아닙니다.

파일시스템에서 새로운 파일을 생성하려면 데이터 공간뿐 아니라 파일의 정보를 관리할 메타데이터 자원도 필요합니다.

대표적인 메타데이터 관리 구조가 inode입니다.

특히 작은 파일이 대량으로 생성되는 환경에서는 디스크 공간보다 inode가 먼저 고갈될 수 있습니다.

예를 들어 용량이 매우 작은 로그 파일 수백만 개가 생성되었다면 전체 데이터 크기는 크지 않더라도 파일마다 필요한 inode 자원이 많이 소비됩니다.

이러한 현상은 로그 수집 서버, 캐시 서버, 이메일 서버, 대량의 임시 파일을 생성하는 애플리케이션에서 발생할 수 있습니다.

Linux inode의 동작 원리

inode는 Linux 파일시스템에서 파일과 디렉터리의 메타데이터를 관리하는 자료구조입니다.

일반적인 inode에는 다음과 같은 정보가 기록됩니다.

항목	설명
inode 번호	파일시스템 내부에서 파일을 식별하는 번호
파일 유형	일반 파일, 디렉터리, 심볼릭 링크 등
접근 권한	읽기, 쓰기, 실행 권한
소유자 정보	UID와 GID
파일 크기	파일 데이터의 크기
시간 정보	접근, 수정, 상태 변경 시간 등
링크 수	해당 inode를 참조하는 하드 링크 수
데이터 위치 정보	파일 데이터 블록을 찾는 데 필요한 정보

파일 이름은 일반적으로 inode 자체가 아니라 디렉터리 항목에 저장됩니다.

디렉터리는 파일 이름과 inode 번호를 연결하며, 커널은 이 정보를 이용해 실제 파일을 찾아갑니다.

구조를 단순화하면 다음과 같습니다.

디렉터리 항목

파일 이름: access.log

inode 번호: 12580

소유자 · 권한 · 파일 크기 · 데이터 위치 정보

데이터 블록

실제 로그 내용이 저장된 공간

새로운 일반 파일이 생성되면 파일시스템은 해당 파일을 관리할 inode를 할당하고, 디렉터리에 파일 이름과 inode 번호의 연결 정보를 기록합니다.

일반 파일뿐 아니라 디렉터리도 inode를 사용합니다. 반면 기존 파일에 하드 링크를 추가하는 경우에는 새로운 파일 inode를 만드는 것이 아니라 기존 inode를 참조합니다.

따라서 inode 소비량은 단순히 파일 데이터의 총용량이 아니라 파일과 디렉터리의 생성 패턴에 영향을 받습니다.

디스크 공간과 inode 사용량이 다른 이유

디스크 공간은 파일의 데이터와 파일시스템 메타데이터 등을 저장하는 데 사용됩니다.

반면 inode 사용량은 파일시스템에서 관리하는 파일 객체의 수와 밀접한 관계가 있습니다.

예를 들어 두 서버에 각각 50GB의 데이터가 저장되어 있다고 가정하겠습니다.

첫 번째 서버는 5GB 파일 10개로 구성되어 있습니다.

두 번째 서버는 5KB 파일 약 1,000만 개로 구성되어 있습니다.

두 서버의 파일 데이터 총용량은 비슷하지만 inode 사용량은 크게 다릅니다.

첫 번째 서버에서는 파일 inode가 소수만 필요하지만 두 번째 서버에서는 수많은 inode가 필요합니다.

이러한 차이 때문에 작은 파일이 계속 증가하는 서버에서는 디스크 사용률이 낮아도 inode가 먼저 부족해질 수 있습니다.

특히 ext4 파일시스템은 생성 시 inode 수가 정해지는 구조이므로 최초 설계가 중요합니다.

반면 XFS는 inode를 동적으로 할당하는 구조를 사용합니다. 다만 XFS 역시 메타데이터 공간과 파일시스템의 자원 제약을 받기 때문에 무제한으로 파일을 생성할 수 있는 것은 아닙니다.

inode 고갈 시 서버에서 나타나는 실제 증상

inode가 부족해지면 단순히 새로운 파일 생성만 실패하는 것이 아닙니다.

서버에서 파일 생성 작업에 의존하는 다양한 기능이 영향을 받을 수 있습니다.

대표적인 증상은 다음과 같습니다.

서버 구성 요소	발생 가능한 증상
Nginx / Apache	로그 파일 생성이나 로그 교체 실패
애플리케이션 서버	임시 파일 및 캐시 파일 생성 실패
데이터베이스	새로운 데이터 파일 또는 임시 파일 생성 실패
메일 서버	메일 파일 저장 실패
백업 시스템	신규 백업 파일 생성 실패
Linux 시스템	PID 파일, 소켓 경로, 기타 상태 파일 생성 실패

예를 들어 애플리케이션이 요청을 처리할 때 임시 파일을 생성하는 구조라면 inode 부족이 직접적인 요청 실패로 이어질 수 있습니다.

로그 파일을 생성하지 못하는 상황도 위험합니다.

애플리케이션이 동작하더라도 오류 로그가 기록되지 않으면 장애 원인을 파악하기 어려워지기 때문입니다.

다만 inode가 고갈되었다고 해서 기존 파일의 모든 읽기와 쓰기 작업이 즉시 중단되는 것은 아닙니다.

이미 생성된 파일은 새로운 inode 할당 없이 데이터를 읽거나 기존 파일에 쓰는 작업이 가능할 수 있습니다. 물론 데이터 블록이 부족하거나 추가 메타데이터 할당이 필요한 작업은 별도로 실패할 수 있습니다.

따라서 inode 고갈 장애는 전체 파일 접근 불능보다는 새로운 파일과 디렉터리를 생성하는 작업부터 실패하는 형태로 나타나는 경우가 많습니다.

inode 사용량을 분석하는 방법

inode 문제를 분석할 때 가장 먼저 확인해야 하는 명령어는 다음과 같습니다.

df -i

이 명령어는 파일시스템별 inode 사용량을 보여줍니다.

출력 예시는 다음과 같습니다.

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

각 항목의 의미는 다음과 같습니다.

항목	의미
Inodes	전체 inode 수
IUsed	사용 중인 inode 수
IFree	사용 가능한 inode 수
IUse%	inode 사용률
Mounted on	파일시스템 마운트 위치

위 결과에서는 inode 사용률이 100%이며 사용 가능한 inode가 없습니다.

이 상태에서는 디스크 공간이 남아 있더라도 새로운 파일 생성이 실패할 수 있습니다.

특정 디렉터리가 속한 파일시스템을 점검하려면 다음 명령어를 사용합니다.

df -h /var/log
df -i /var/log

첫 번째 명령어는 디스크 공간을 확인하고 두 번째 명령어는 inode 사용량을 확인합니다.

두 결과를 함께 비교해야 저장 공간 부족인지 inode 부족인지 구분할 수 있습니다.

또한 파일시스템 유형도 확인할 수 있습니다.

df -T /var/log

여기서 ext4인지 XFS인지 확인하면 inode 구조에 따른 대응 방법을 결정하는 데 도움이 됩니다.

inode를 많이 사용하는 디렉터리 찾기

inode 사용량이 높다는 사실을 확인했다면 다음 단계는 파일이 집중적으로 생성되는 디렉터리를 찾는 것입니다.

일반적으로 다음과 같은 경로를 우선 조사합니다.

/var/log
/var/cache
/var/tmp
/tmp

다만 모든 서버에서 이러한 디렉터리가 문제의 원인이 되는 것은 아닙니다.

실제 파일 생성 경로는 애플리케이션 구조에 따라 다릅니다.

특정 경로 아래의 파일과 디렉터리 수를 확인하려면 다음 명령어를 사용할 수 있습니다.

find /var/log -xdev -printf '.' | wc -c

이 명령어는 /var/log 아래에서 찾은 항목 수를 계산합니다.

여기에는 파일과 디렉터리 등이 포함됩니다.

-xdev 옵션은 다른 파일시스템으로 탐색이 넘어가지 않도록 제한합니다.

다만 이 결과가 inode 사용량과 항상 정확히 일치하는 것은 아닙니다. 하드 링크나 이미 삭제되었지만 프로세스가 사용 중인 파일 등의 영향을 받을 수 있습니다.

상위 디렉터리별 항목 수를 비교하려면 다음과 같이 점검할 수도 있습니다.

for dir in /var/log/*; do
    [ -d "$dir" ] || continue
    printf '%s ' "$dir"
    find "$dir" -xdev -printf '.' | wc -c
done

명령어 실행 결과 특정 애플리케이션의 로그 디렉터리에 파일이 집중되어 있다면 해당 애플리케이션의 로그 생성 주기와 삭제 정책을 점검해야 합니다.

주의할 점은 find 명령어가 실제 디렉터리 항목을 탐색한다는 것입니다.

파일 수가 수백만 개 이상인 환경에서는 탐색 작업 자체가 디스크 I/O와 메타데이터 부하를 발생시킬 수 있습니다.

운영 서버에서는 가능한 한 조사 범위를 제한하고, 트래픽이 적은 시간대에 점검하는 것이 좋습니다.

ext4 파일시스템의 inode 개수 확인

ext4 파일시스템은 일반적으로 파일시스템 생성 시 inode 수가 결정됩니다.

따라서 동일한 디스크 용량이라도 파일시스템 생성 설정에 따라 사용 가능한 inode 수가 다를 수 있습니다.

현재 ext4 파일시스템의 inode 정보를 확인하려면 다음 명령어를 사용할 수 있습니다.

sudo tune2fs -l /dev/sda1

출력 중 다음 항목을 확인합니다.

Inode count:              6553600
Free inodes:              125000
Inodes per group:         8192
Inode size:               256

Inode count는 전체 inode 수를 나타내고 Free inodes는 남아 있는 inode 수를 의미합니다.

이때 디스크 장치 이름은 실제 서버 환경에 맞게 확인해야 합니다.

특히 LVM, RAID, 클라우드 블록 스토리지 환경에서는 /dev/sda1이 아니라 다른 장치 경로가 사용될 수 있습니다.

또한 ext4에서는 일반적으로 기존 파일시스템을 유지한 채 inode 수만 간단히 늘릴 수 없습니다.

파일시스템 확장 과정에서 inode가 추가될 수는 있지만, 원하는 inode 밀도로 조정하려면 파일시스템 재생성이 필요할 수 있습니다.

따라서 장기적으로 작은 파일이 대량 생성되는 구조라면 초기 파일시스템 설계 단계에서 예상 파일 수를 고려해야 합니다.

inode 부족 문제를 해결하는 방법

inode 부족 문제를 해결하기 위해서는 사용하지 않는 파일을 정리하고, 파일 생성 구조 자체를 개선해야 합니다.

가장 먼저 로그와 캐시 파일의 보존 기간을 확인합니다.

예를 들어 다음 명령어는 지정된 디렉터리에서 30일보다 오래된 일반 파일을 찾습니다.

find /var/log/myapp -type f -mtime +29 -print

삭제하기 전에 반드시 파일 목록과 보존 필요성을 확인해야 합니다.

점검 후 불필요한 파일로 확정된 경우에만 정리합니다.

find /var/log/myapp -type f -mtime +29 -delete

이 명령어는 실제 파일을 삭제하므로 운영 서버에서는 매우 신중하게 사용해야 합니다.

특히 감사 로그, 보안 로그, 법적 보존 의무가 있는 로그는 임의로 삭제해서는 안 됩니다.

로그가 지속적으로 쌓이는 환경에서는 logrotate와 같은 로그 관리 기능을 활용하는 것이 좋습니다.

다만 로그 파일을 주기적으로 압축하는 것만으로 inode 문제가 해결되는 것은 아닙니다.

여러 파일을 각각 압축해도 파일 수가 크게 줄어들지 않을 수 있기 때문입니다.

inode 사용량을 줄이려면 불필요한 파일을 삭제하거나 여러 파일을 하나의 보관 파일로 묶는 등의 방법을 검토해야 합니다.

임시 파일과 캐시 파일도 생성 수명과 정리 주기를 관리하는 것이 중요합니다.

애플리케이션이 요청마다 별도의 파일을 만들고 삭제하지 않는 구조라면 inode 문제는 반복해서 발생할 수밖에 없습니다.

파일을 삭제했는데 inode가 반환되지 않는 이유

파일을 삭제했는데도 inode 사용량이 예상만큼 줄어들지 않는 경우가 있습니다.

대표적인 원인은 삭제된 파일을 프로세스가 계속 열고 있는 상황입니다.

Linux에서는 파일 이름이 삭제되더라도 해당 파일을 사용 중인 프로세스가 파일 디스크립터를 유지하고 있다면 파일의 inode가 즉시 해제되지 않을 수 있습니다.

이러한 상태를 확인하려면 다음 명령어를 사용할 수 있습니다.

sudo lsof +L1

이 명령어는 링크 수가 1 미만인 열린 파일을 찾는 데 사용합니다.

삭제된 파일을 프로세스가 계속 사용하고 있다면 출력 결과에서 관련 프로세스와 파일 정보를 확인할 수 있습니다.

이후 해당 프로세스가 파일을 닫도록 처리해야 합니다.

필요한 경우 애플리케이션의 정상적인 재시작이나 로그 재오픈 절차를 검토할 수 있습니다.

하지만 무조건 프로세스를 강제 종료하는 것은 위험합니다.

서비스 중단이나 데이터 손실이 발생할 수 있으므로 먼저 파일의 용도와 프로세스 상태를 파악해야 합니다.

또한 파일이 삭제되었음에도 프로세스가 사용 중인 문제는 디스크 공간이 반환되지 않는 현상의 원인이기도 합니다.

따라서 inode 고갈과 디스크 사용량 이상을 분석할 때 함께 확인할 필요가 있습니다.

운영 환경에서 inode 고갈을 예방하는 방법

inode 문제는 장애가 발생한 이후 정리하는 것보다 사전에 감시하는 것이 효과적입니다.

일반적인 디스크 모니터링에서는 디스크 사용률만 수집하는 경우가 많습니다.

하지만 디스크 사용률이 정상이어도 inode가 부족해질 수 있으므로 inode 사용률을 별도로 수집해야 합니다.

예를 들어 모니터링 시스템에서 다음 항목을 관리할 수 있습니다.

모니터링 항목	확인 목적
디스크 사용률	데이터 저장 공간 부족 감지
inode 사용률	파일 생성 자원 부족 감지
디렉터리별 파일 수	특정 경로의 파일 급증 감지
로그 생성량	로그 폭증 및 비정상 요청 탐지
임시 파일 증가량	애플리케이션의 파일 정리 문제 탐지

inode 사용률이 일정 수준을 넘으면 알림을 발생시키도록 설정할 수 있습니다.

예를 들어 80%에서 경고, 90%에서 위험 알림을 설정하는 방식입니다.

다만 이러한 수치는 모든 서버에 동일하게 적용되는 절대적인 기준이 아닙니다.

파일 생성 속도가 빠른 서버라면 inode 사용률이 70%인 상황에서도 단시간에 고갈될 수 있습니다.

반대로 파일 수 변화가 거의 없는 서버라면 상대적으로 여유 있게 대응할 수 있습니다.

따라서 현재 사용률뿐 아니라 inode 소비 속도와 예상 고갈 시점까지 함께 관리하는 것이 바람직합니다.

장기적으로는 파일을 무분별하게 생성하는 구조를 개선하고, 로그와 캐시의 수명주기를 명확히 설계해야 합니다.

정리

Linux 서버에서 디스크 공간이 충분한데도 파일 생성이 실패한다면 inode 부족 여부를 반드시 확인해야 합니다.

inode는 파일과 디렉터리의 메타데이터를 관리하는 핵심 구조이며, 파일시스템은 새로운 파일을 생성할 때 필요한 inode 자원을 할당해야 합니다.

특히 작은 파일이 대량으로 누적되는 환경에서는 디스크 사용량보다 inode 사용량이 먼저 한계에 도달할 수 있습니다.

문제를 분석할 때는 df -h와 df -i를 함께 사용해 디스크 공간과 inode 사용량을 구분해야 합니다. 이후 파일 수가 급증한 디렉터리를 조사하고, 로그와 캐시의 생성 및 삭제 정책을 점검해야 합니다.

파일을 삭제했는데도 자원이 반환되지 않는다면 프로세스가 삭제된 파일을 계속 열고 있는지도 확인할 필요가 있습니다.

궁극적으로 inode 고갈을 예방하려면 단순히 디스크 용량을 늘리는 것이 아니라 파일시스템 구조, 파일 생성 패턴, 로그 관리 정책, inode 모니터링을 함께 설계해야 합니다.

서버의 저장 공간이 충분하다는 사실만으로 파일시스템 자원까지 충분하다고 판단해서는 안 됩니다.