새벽 3시, 주문 서버(order-01)의 애플리케이션 로그에 'no space left on device'가 쏟아지고 고객 첨부 파일 업로드가 전부 실패합니다. 그런데 디스크 사용률 경보(85%)는 울리지 않았습니다. 온콜 담당자는 df -h에서 /data가 38%인 것을 보고 "디스크는 멀쩡하니 애플리케이션 버그"라며 개발팀을 깨우려 합니다. 이 서버에는 한 달 전부터 상품 이미지 썸네일을 만드는 배치가 1분마다 돌고 있고, 원본 이미지가 없으면 '다음 실행 때 다시 시도'하도록 만들어져 있습니다.
디스크는 38%인데 No space left on device: 파일 업로드가 실패하는 inode 고갈
새벽 3시, 주문 서버(order-01)의 애플리케이션 로그에 'no space left on device'가 쏟아지고 고객 첨부 파일 업로드가 전부 실패합니다.
시나리오
단서
Filesystem Size Used Avail Use% Mounted on /dev/nvme1n1 200G 76G 125G 38% /data Filesystem Inodes IUsed IFree IUse% Mounted on /dev/nvme1n1 13107200 13107200 0 100% /data
2026-09-27 03:02:11 ERROR upload failed: open /data/uploads/tmp/up_8f3a.part: no space left on device 2026-09-27 03:02:14 ERROR upload failed: open /data/uploads/tmp/up_91c0.part: no space left on device
1204 /data/uploads 12950310 /data/thumb-cache/tmp 12951622 /data
* * * * * /opt/thumb/run.sh >> /var/log/thumb.log 2>&1 2026-09-27 03:01:02 WARN source missing for sku 88213, keep /data/thumb-cache/tmp/th_88213_1790449262.tmp for retry 2026-09-27 03:01:02 WARN source missing for sku 88214, keep /data/thumb-cache/tmp/th_88214_1790449262.tmp for retry
과제 업로드가 실패하는 원인을 좁히고, 서비스를 되살리는 순서(검증 포함)와 재발 방지책을 적어 보세요.
구독하면 이어서 볼 수 있어요
이 문제의 전체 시나리오와 점검 체크리스트, 복구 순서, 모범 풀이는 Pro 구독에서 열립니다.
먼저 볼 것
- 'No space left on device'가 나는 두 가지 경우(용량·inode) 구분하기
- 파일 개수가 많이 쌓인 디렉터리 찾기
- 지우기 전에 쌓는 쪽부터 멈추기
점검 체크리스트
- df -h 와 df -i 를 함께 보고 무엇이 먼저 고갈됐는지 확인
- du --inodes -x -d 2 /data — 파일 개수가 몰린 디렉터리 찾기
- crontab·systemd 타이머에서 그 디렉터리에 파일을 만드는 작업 찾기
- 지운 뒤 df -i 로 IFree가 늘었는지 확인
복구와 재발 방지
같이 보면 좋은 질문
현장에서 본 비슷한 케이스
0/10