파일 하나를 저장하려는데 No space left on device가 나옵니다. 디스크 사용률은 100%가 아니고, 큰 파일을 지웠는데도 상황이 그대로라면 조금 막막해져요. 이때는 용량을 더 지우기 전에 오류가 난 경로의 파일시스템과 inode부터 확인하는 편이 좋습니다.
아래 명령은 Rocky Linux와 Ubuntu처럼 GNU 도구를 사용하는 리눅스를 기준으로 합니다. 예시 경로는 /var/log입니다. 애플리케이션이 파일을 쓰다가 실패했다면 그 프로그램의 실제 저장 디렉터리로 바꿔 실행하세요.
이 글의 목차
오류가 난 경로에서 df를 확인합니다
df -h /var/log
df -i /var/log
findmnt -T /var/logdf -h는 해당 경로가 속한 파일시스템의 용량을, df -i는 inode 사용량을 보여줍니다. inode는 파일의 소유자·권한·데이터 위치 같은 정보를 담는 구조예요. 빈 파일도 inode를 사용하므로 작은 파일이 많으면 남은 바이트와 별개로 파일 생성이 막힐 수 있습니다.
서버 전체의 df -h 출력만 보면 다른 디스크의 여유 공간을 보고 안심하기 쉽습니다. /에는 공간이 있어도 /var, 컨테이너의 쓰기 계층, 크기가 제한된 tmpfs는 가득 찰 수 있어요. findmnt의 TARGET, SOURCE, FSTYPE을 보고 지금 확인하는 대상부터 맞춥니다.
| 확인 결과 | 다음에 볼 곳 |
|---|---|
대상 파일시스템의 Avail이 거의 없음 | 같은 파일시스템에서 큰 디렉터리와 증가 원인 확인 |
IFree가 없거나 inode 사용률이 매우 높음 | 캐시·세션·작은 파일이 몰린 디렉터리 확인 |
| 파일을 지워도 사용량이 줄지 않음 | 삭제된 파일을 계속 열고 있는 프로세스 확인 |
| 호스트에는 여유가 있는데 컨테이너에서만 실패 | 컨테이너 내부의 경로·마운트·tmpfs 제한 확인 |
파일시스템에 따라 inode를 할당하는 방식은 다릅니다. ext4의 inode 고갈 사례를 XFS에 그대로 대입하지 말고, 사용 중인 파일시스템과 실제 출력으로 판단합니다. 사용자 할당량 초과는 보통 Disk quota exceeded라는 별도 오류로 나타나므로 함께 구분해 두세요.
용량이 부족하면 같은 파일시스템 안에서 좁혀갑니다
sudo du -x -h --max-depth=1 /var/log | sort -hdu는 디렉터리 아래에서 접근할 수 있는 파일들의 사용량을 집계합니다. -x는 다른 파일시스템으로 넘어가지 않게 합니다. 큰 하위 디렉터리를 찾으면 그 경로를 대상으로 같은 명령을 반복하면 돼요. 시스템 전체를 매번 훑는 것보다 조사 범위와 디스크 읽기 부담을 줄일 수 있습니다.
읽기 권한 오류가 나면 집계가 빠질 수 있으므로 오류도 함께 봅니다. df와 du가 정확히 같아야 하는 것은 아닙니다. 파일시스템 메타데이터, 예약 공간, 스냅샷, 공유 블록 등의 영향도 있어요. 차이가 크다는 이유만으로 파일시스템 손상이라고 단정하지 않습니다.
큰 파일을 발견했어도 프로그램이 계속 쓰는 데이터인지 먼저 확인합니다. 데이터베이스 파일이나 컨테이너 저장소 디렉터리를 파일 관리 명령으로 직접 삭제하면 복구가 어려워질 수 있습니다. 로그는 해당 서비스의 회전·보관 설정으로, 컨테이너 데이터는 소유한 서비스와 볼륨을 확인한 뒤 정리합니다.
inode가 부족하면 큰 파일보다 파일 개수를 봅니다
sudo du -x --inodes --max-depth=1 /var | sort -n여기서는 크기 대신 inode 사용량이 나옵니다. 숫자가 큰 디렉터리를 다시 내려가 보세요. 세션 파일, 메일 큐, 작업 임시 파일처럼 작은 파일이 쌓이는 위치를 찾는 데 도움이 됩니다. du --inodes가 없는 도구 환경에서는 먼저 du --help로 지원 여부를 확인합니다.
파일 개수가 많다고 전부 불필요한 파일은 아닙니다. 생성 프로그램, 보관 기간, 현재 사용 여부를 확인하고 프로그램이 제공하는 정리 기능부터 사용합니다. 파일을 지우는 속도보다 생성 속도가 빠르다면 재시도 루프나 만료 처리 실패도 함께 고쳐야 해요.
지운 파일을 프로세스가 계속 잡고 있을 수 있습니다
리눅스에서는 파일 이름을 지워도 프로세스가 파일을 열고 있으면 그 데이터가 즉시 해제되지 않을 수 있습니다. 디렉터리를 훑는 du에서는 사라졌는데 df 사용량은 남는 대표적인 상황입니다. lsof가 설치된 서버에서는 다음처럼 확인합니다.
sudo lsof +L1+L1은 링크 수가 1보다 작은 열린 파일을 고릅니다. 출력의 COMMAND, PID, SIZE/OFF, NAME을 보고 문제의 파일시스템에서 큰 파일을 잡고 있는 프로세스를 찾습니다. 출력이 없다고 모든 공간 문제의 원인이 배제되는 것은 아닙니다.
대상 서비스가 확인되면 로그 다시 열기 기능이나 정상적인 재시작 절차를 사용합니다. 재시작이 연결 중단이나 작업 실패로 이어질 수 있으므로 서비스 영향을 먼저 확인해야 합니다. /proc/.../fd/...에 직접 쓰거나 프로세스를 강제로 종료하는 방법은 기본 정리 절차로 사용하지 않습니다.
컨테이너에서는 안쪽 경로도 따로 확인합니다
호스트의 디스크와 컨테이너가 보는 저장 공간이 같은 조건인지 확인합니다. 아래의 myapp은 조사할 컨테이너 이름으로 바꾸세요. 컨테이너 이미지에 셸이나 df가 없으면 docker inspect의 마운트 정보를 바탕으로 호스트 쪽 저장 경로를 조사합니다.
docker inspect myapp --format '{{json .Mounts}}'
docker inspect myapp --format '{{json .HostConfig.Tmpfs}}'
docker exec myapp df -h /tmp
docker exec myapp df -i /tmp파일을 쓰는 위치가 /tmp라면 디스크가 아니라 제한된 메모리 파일시스템이 찼을 수도 있습니다. 바인드 마운트라면 Mounts의 Source를 호스트에서 확인합니다. 이름이 비슷한 다른 볼륨을 정리하지 않도록 컨테이너의 Destination과 함께 맞춰 보세요.
조치 후에는 파일 생성과 증가 원인을 확인합니다
정리 후에는 같은 경로에서 df -h, df -i를 다시 확인하고, 실패했던 프로그램 작업을 다시 실행합니다. 파일 생성이 정상으로 돌아와도 로그나 임시 파일이 계속 빠르게 늘면 같은 문제가 되풀이됩니다. 보관 기간과 정리 작업의 실행 결과까지 남겨 두면 다음 점검이 편해요.
실제 데이터 증가로 용량이 부족하다면 LVM·XFS·ext4 루트 확장 또는 LVM 없는 파티션 확장에서 현재 구조에 맞는 절차를 확인할 수 있습니다.
이 글을 준비하며 별도 임시 디렉터리에서 8 MiB 파일을 삭제한 뒤 열린 파일 디스크립터가 유지되는 동작과, 빈 파일 생성에 따른 inode 사용 증가를 확인했습니다. 운영 디스크를 가득 채우거나 실제 서비스 파일을 삭제하는 실험은 하지 않았습니다.
