기술 · 실용 가이드
Linux가 “No space left on device”라는데 df에는 공간이 있나요? 실패한 정확한 경로부터 확인하세요
ENOSPC는 확인한 파일시스템이 가득 찼다는 증거가 아닙니다. 실패 경로를 실제 mount와 storage backend에 연결한 뒤 block, inode, 삭제됐지만 열린 파일, quota, overlay와 파일시스템 제한을 순서대로 검사하세요.
“No space left on device”는 한 번의 실패한 작업이 반환한 오류입니다. 인자 없는 df에서 본 filesystem이 실패 대상이거나 부족한 자원이 byte뿐이라는 뜻은 아닙니다.
정확한 실패 path를 보존하고 그 path의 mount, filesystem type과 storage boundary를 확인하세요. 같은 path에서 block과 inode를 검사한 뒤 증거에 따라 deleted-open file, hidden mount, quota, container layer 또는 filesystem allocation으로 분기합니다.
cleanup 전에 실패 path 보존
전체 error, command, timestamp와 destination path를 저장하세요. application이 path를 숨기면 정상 diagnostic log를 늘리거나 한 번만 제한적으로 재현합니다.
write가 host, container, bind mount, CI workspace 또는 다른 storage service에서 일어났는지 기록하세요. 같은 디렉터리 이름도 다른 backend일 수 있습니다.
df에 정확한 path를 질의
실패 path나 존재하는 parent에 df를 실행하고 Filesystem, Type, Size, Avail, Mounted on을 저장하세요. 같은 path에서 inode도 확인합니다.
path가 아직 없다면 가장 가까운 기존 parent까지 올라가 mount view를 저장하고, 별도 /var, bind mount, overlay 또는 network filesystem을 /와 혼동하지 마세요.
block capacity와 inode capacity 분리
block이 부족하면 해당 filesystem 안에서만 큰 consumer를 찾고 retention과 owner를 확인한 뒤 삭제하세요. 의도 없이 다른 mount를 넘지 마세요.
inode가 부족하지만 block은 남아 있다면 매우 많은 small file을 만드는 directory를 찾으세요. byte capacity 증설이 모든 filesystem에서 inode를 늘리지는 않습니다.
증거를 잃지 않고 df와 du 차이 설명
df allocation이 directory scan보다 크면 process가 잡고 있는 deleted file을 검사하세요. PID, service, fd와 size를 기록한 뒤 restart, reload 또는 truncate를 결정합니다.
mount point 아래 숨은 이전 file도 확인하세요. production unmount는 service를 중단하므로 maintenance window나 안전한 namespace를 사용합니다.
quota·container·filesystem limit 확인
block과 inode가 정상이라면 실제 writer의 user/group/project quota와 reserved allocation을 확인하세요. container는 storage root, driver, writable layer와 host backend를 기록합니다.
그다음 metadata, snapshot, copy-on-write reservation, pool capacity를 filesystem 전용 tool로 검사하세요. ext4 판단을 다른 filesystem에 그대로 적용하지 마세요.
증명된 한 분기만 수정하고 같은 write 검증
정책에 따른 정리, log rotation, 확인된 open file 해제, 정확한 volume 증설, 근거 있는 quota 조정 또는 documented migration 중 가장 작고 되돌릴 수 있는 조치를 선택하세요.
원래 write를 한 번만 다시 실행하고 같은 target path에서 capacity, inode 또는 quota headroom을 확인하세요. 일시적 감소와 지속적 회복을 구분합니다.
