inode 다 찼을 때 파일이 안 저장되는 이유와 해결법

Views: 0

inode와 블록: 왜 공간이 남아도 저장이 안 되나

리눅스 파일시스템은 데이터를 담는 블록 공간과, 파일의 메타데이터를 담는 inode 풀을 별도로 관리한다. 각 일반 파일·디렉터리·FIFO 등은 최소 1개의 inode를 점유한다. 블록이 남아 있어도 inode가 0이면 커널은 새 파일을 만들 수 없어 ENOSPC 오류를 낸다. 커널 문서에서는 inode가 파일 메타데이터(소유권, 권한, 타임스탬프, 블록 매핑 등)를 담는다고 설명한다. 이 때문에 “디스크가 안 찼는데 저장이 안 된다”는 역설이 생긴다.
참고: Linux VFS/inode 개요(kernel.org) 및 ext4 inode 설명(kernel.org)
https://www.kernel.org/doc/html/next/filesystems/vfs.html
https://www.kernel.org/doc/html/latest/filesystems/ext4/inodes.html

증상은 이렇게 나타난다

  • 애플리케이션이 파일 생성 시 실패하며 “No space left on device”가 출력된다
  • df -h로는 사용률이 여유 있는 것처럼 보이지만, df -i에서 IUse%가 100%
  • 임시 파일을 많이 쓰는 서비스나, 수백만 개의 작은 파일을 쌓는 배치 작업 이후 급격히 발생

특히 “작은 파일이 엄청나게 많은” 워크로드는 디스크를 거의 쓰지 않아도 inode를 먼저 소모한다. 운영 현장에서 흔하다.
관련 설명: https://stackoverflow.com/questions/653096/how-to-free-inode-usage

빠른 진단 절차

1) inode 상태 확인

  • 전체: df -i
  • 특정 마운트만: df -iT | grep -E 'ext4|xfs|btrfs'

2) 어느 디렉터리가 inode를 잡아먹는지 파악

  • 상위 디렉터리별 inodes 합계:
    sudo du --inodes -x / -d 5 | sort -nr | head
    -x는 다른 파일시스템으로 넘어가지 않도록 제한한다.
  • 작은 파일이 많은 경로 찾기:
    find /path -xdev -type f -size -4k | wc -l

3) “지워도 용량이 안 줄어드는” 상황 구분

파일을 지워도 공간이 회수되지 않는 경우가 있다. 삭제(unlink)된 파일을 어떤 프로세스가 계속 열고 있으면, 링크 수가 0이어도 마지막 참조가 닫힐 때까지 데이터와 inode가 남는다. 이런 흔적은 lsof로 찾는다.

즉시 적용 가능한 해결책(운영 중 조치)

1) 불필요한 작은 파일 대청소

  • 애플리케이션 캐시 디렉터리, 빌드 아티팩트, 오래된 임시 파일을 우선 정리
  • 패키지 캐시(예: /var/cache/*)는 정책에 맞춰 주기 삭제
  • 수십만 개 파일을 한 번에 삭제하면 부담이 크다. find … -delete 대신 날짜·패턴을 나눠 단계적으로 지우면 부하가 낮다.

2) 로그 회전과 압축 정책 강화

  • logrotate에서 daily/hourly, 보관 개수(rotate), 압축(compress, delaycompress), 파일 분할 기준(size, maxsize)을 현실적으로 조정
  • 하나의 거대 로그보다 수십만 개의 초소형 로그가 inode 소모에 치명적이다. 가능한 한 파일 수를 줄이고 압축을 적극 사용한다.

3) 삭제했는데 공간·inode가 안 돌아올 때

  • lsof +L1로 (deleted) 상태 파일을 잡아내고, 해당 프로세스를 재시작해 파일 핸들을 닫게 한다.
  • 재시작이 어렵다면, 프로세스가 가리키는 /proc/<PID>/fd/<N>에 0바이트를 덮어써 임시로 블록 공간을 회수하는 방법도 있다. 다만 이는 응용의 동작에 영향을 줄 수 있으니 점검 창구에서 수행한다.
    기술 배경: https://stackoverflow.com/questions/18200701, https://serverfault.com/questions/501963

4) 디렉터리 구조 재정비

  • “파일 1개당 1레코드” 같은 설계를 피하고, 주기적으로 아카이브하여 tar·zip 등으로 묶는다
  • 타임스탬프 분할 디렉터리(연/월/일)로 폴더당 파일 수를 제한해 디렉터리 엔트리 확장을 완화

장기 해법(재발 방지 전략)

1) 워크로드 구조 개선

  • 작은 파일 폭증을 유발하는 패턴(세션 조각, 미세 로그, 임시 아티팩트)을 파악
  • 스트리밍·배치 파이프라인 단계에서 먼저 묶고 압축하여 파일 개수를 줄인다
  • DB나 오브젝트 스토리지(S3 호환 등)로 로그·이벤트를 수렴시키면 파일시스템 inode 부담이 크게 줄어든다

2) 파일시스템 재구성 시 고려사항

  • ext4는 파일시스템 생성 시 inode 비율을 조절할 수 있다(mkfs.ext4 -i, -T 프로파일). 작은 파일이 많은 서버라면 더 촘촘한 inode 비율을 설계한다.
  • XFS는 inode를 영역 단위로 미리 할당하고 동적으로 확장하지만, 생성 시의 할당 정책과 inode 크기(mkfs.xfs -i size=)가 영향을 준다.
  • 어떤 FS든 “이미 만들어진 파티션의 inode 개수 자체”를 큰 폭으로 늘리기는 어렵다. 새로 포맷하거나 데이터를 이관해 재구성하는 선택지가 필요할 수 있다.
    개념 참고: https://man7.org/linux/man-pages/man7/inode.7.html

3) 모니터링과 얼리 워닝

  • 메트릭: node_filesystem_files_free, node_filesystem_files(Prometheus), inodes_free/inodes_total(각 에이전트)
  • 경보 기준: IUse% 85% 이상 시 경고, 95% 이상 시 치명 경보
  • “개수”뿐 아니라 “증가 속도”를 함께 보아 피크 타임 이전에 자동 정리 작업을 트리거

운영 시 유의해야 할 디테일

  • 수백만 파일 삭제는 자체가 I/O 폭탄이 될 수 있다. 서비스 피크 타임을 피하고, ionice/nice로 우선순위를 낮춰 실행한다.
  • inode 회복에는 디렉터리·심볼릭 링크도 포함된다. 빈 디렉터리 대량 생성 습관을 피한다.
  • 컨테이너 환경에서는 이미지 풀 캐시, 레이어의 작은 파일이 대거 남을 수 있다. 노드별 정기 정리 정책을 별도로 둔다.
  • 파일시스템마다 디렉터리 확장 방식이 달라 대량 엔트리 시 메타데이터 I/O 성능 차이가 있다. 구조적 분산이 성능과 inode 절감을 동시에 돕는다.
    추가 개념 참고: https://web.stanford.edu/class/archive/cs/cs111/cs111.1232/lectures/4/Lecture4.pdf, https://cs162.org/static/dis/9.pdf

체크리스트: 현장에서 바로 쓰는 레시피

  1. df -i로 IUse% 확인
  2. du --inodes -x로 상위 점유 경로 파악
  3. 불필요한 작은 파일·캐시 단계적 삭제
  4. logrotate로 파일 수를 줄이고 압축 강화
  5. lsof +L1로 (deleted) 열린 파일을 찾아 프로세스 재시작
  6. 아카이브 정책 도입으로 “작은 파일 폭증” 근본 해소
  7. 재발 방지를 위해 inode 비율·파일시스템 설계를 재검토

마무리

inode 고갈은 디스크 사용률만 보던 운영 습관의 사각지대에서 자주 터진다. 원리를 정확히 이해하고, 수치 기반 점검(df -i, du —inodes), 로그·임시 파일 정책 개선, 필요 시 파일시스템 재설계를 병행하면 같은 장애를 반복하지 않는다. 결국 핵심은 “파일 개수와 생성 패턴을 줄이는 구조”로의 전환이다.

참고 자료

정보 추천글 더보기