beautifulsoups.dev
Published on

리눅스 디스크 100% - 삭제해도 용량 안 줄 때

Authors

서버에서 rm -rf로 로그나 임시 파일을 잔뜩 지웠는데도 df -h가 여전히 100%라면, 단순히 “삭제가 안 됐나?” 수준이 아니라 리눅스 파일 시스템의 동작 방식(링크 카운트, 열린 파일 디스크립터, 오버레이/마운트 구조, inode) 때문에 발생하는 전형적인 함정일 가능성이 큽니다.

이 글에서는 “삭제했는데 용량이 안 줄어드는” 상황을 재현 가능한 체크리스트로 풀어가며, 운영 환경에서 안전하게 조치하는 방법까지 정리합니다.

1) 먼저 확인: df와 du가 다르면 ‘삭제해도 안 줄어드는’ 케이스일 확률이 높다

가장 먼저 아래 두 값을 비교합니다.

  • df -h: 파일시스템이 실제로 인식하는 사용량(블록 사용량)
  • du -sh: 디렉터리 트리 기준으로 보이는 사용량
# 파일시스템 전체 관점
df -hT /

# 디렉터리 트리 관점(루트 기준, 다른 마운트는 제외)
du -xhd1 / | sort -h

해석 포인트

  • df는 100%인데 du는 생각보다 작다 → 대개 “삭제된 파일을 어떤 프로세스가 아직 열고 있음” 또는 “마운트/오버레이로 인해 du가 못 보는 영역이 있음”
  • du도 크다 → 실제로 파일이 남아 있거나(숨김 디렉터리, 로그 폭증), 스냅샷/서브볼륨, 컨테이너 레이어 등이 원인일 수 있음

2) 가장 흔한 원인: 삭제된 파일을 프로세스가 계속 잡고 있는 경우

리눅스에서는 파일을 삭제(unlink)해도 어떤 프로세스가 그 파일을 열고 있으면 디스크 블록이 즉시 반환되지 않습니다. 즉, “경로는 사라졌지만 디스크는 계속 사용 중”인 상태가 됩니다.

2-1) 열린 삭제 파일 찾기: lsof +L1

# 링크 카운트가 0(삭제됨)인데 열린 파일
sudo lsof +L1

# 특정 파일시스템/마운트에 대해서만 보고 싶으면 경로를 제한
sudo lsof +L1 /var

출력에서 deleted 표시가 붙은 대용량 파일이 보이면 거의 확정입니다.

2-2) 해결: 프로세스 재시작(또는 로그 로테이션 재적용)

가장 안전한 방법은 해당 프로세스를 재시작해서 파일 디스크립터를 닫게 만드는 것입니다.

# 예: nginx
sudo systemctl restart nginx

# 예: journald
sudo systemctl restart systemd-journald

서비스 재시작이 어려운 경우, 프로세스에 따라 로그 파일을 다시 열도록 시그널을 보낼 수 있습니다(예: nginx는 USR1, 일부는 HUP).

# nginx 예시(환경에 따라 다름)
sudo kill -USR1 $(cat /run/nginx.pid)

> 주의: /proc/<pid>/fd/<n>을 직접 건드려 :> file로 비우는 트릭도 있지만, 운영 환경에서는 서비스별 로깅 동작을 이해하지 못한 상태로 적용하면 장애를 유발할 수 있어 권장하지 않습니다.

3) 로그 로테이션이 꼬였을 때: “지웠는데도 계속 쌓이는” 패턴

삭제 후에도 다시 금방 100%가 되는 경우는 로그가 계속 생성되거나, 로테이션 정책이 깨져서 압축/삭제가 안 되는 경우가 많습니다.

3-1) journald가 디스크를 먹는지 확인

journalctl --disk-usage

# 과도하면 상한을 걸고 정리
sudo journalctl --vacuum-time=7d
# 또는
sudo journalctl --vacuum-size=1G

/etc/systemd/journald.conf에서 상한을 고정하는 것도 장기적으로 유효합니다.

# /etc/systemd/journald.conf
SystemMaxUse=1G
RuntimeMaxUse=200M

3-2) logrotate 상태 확인

sudo logrotate -d /etc/logrotate.conf   # dry-run
sudo logrotate -f /etc/logrotate.conf   # 강제 실행(주의)
  • 로테이션 대상 파일 권한/소유권 문제
  • copytruncate 필요 여부
  • 서비스가 새 파일을 다시 열지 못하는 문제

등을 점검합니다.

4) df는 100%인데 “용량은 남아 보이는” 또 다른 축: inode 고갈

블록(용량)은 남아 있어도 **inode가 100%**면 파일을 더 만들 수 없고, 상황에 따라 “No space left on device”가 발생합니다. 이 경우 사용자는 흔히 “용량 남는데 왜?”라고 느끼게 됩니다.

df -ih
  • IUse%가 100%에 가깝다면 작은 파일이 과도하게 쌓인 것입니다(캐시, 세션 파일, 작은 로그 등).

이 케이스는 별도 글에서 더 깊게 다뤘습니다: No space left on device인데 용량 남을 때 - inode 0% 해결

5) 컨테이너/쿠버네티스에서 자주 겪는 착시: overlay2, emptyDir, PV 마운트

도커/컨테이너 환경에서는 df와 du가 더 자주 엇갈립니다.

5-1) 도커 overlay2가 디스크를 먹는지 확인

docker system df
sudo du -sh /var/lib/docker/* 2>/dev/null

불필요한 이미지/컨테이너/볼륨이 쌓였으면 정리합니다.

# 사용하지 않는 것 정리(운영 환경에서는 범위를 반드시 확인)
docker image prune -a
docker container prune
docker volume prune

5-2) 쿠버네티스 노드에서 ephemeral storage 폭증

  • emptyDir가 커졌거나
  • 로그가 노드 로컬에 쌓였거나
  • 이미지 풀/레이어가 누적

인 경우가 많습니다. 노드에서 디스크가 가득 차면 파드가 연쇄적으로 죽을 수도 있어, 메모리 OOM처럼 “자원 관리” 관점에서 접근해야 합니다. (리소스/제한을 다루는 관점은 GitLab Runner Docker executor OOM·Exit 137 해결 글의 트러블슈팅 흐름도 참고가 됩니다.)

6) “삭제했는데도 안 줄어드는” 특수 케이스들

6-1) 마운트 포인트 착각(다른 파일시스템에 지웠다)

예를 들어 /data가 별도 디스크로 마운트돼 있는데, 실제로 가득 찬 건 /이고 사용자는 /data를 정리하는 식의 착각이 생길 수 있습니다.

findmnt -T /
findmnt -T /var
findmnt -T /data

# 마운트별 사용량
df -hT

6-2) 숨겨진 디렉터리/백업 파일

du로 상위만 보면 놓칠 수 있습니다.

sudo du -xhd1 /var | sort -h
sudo du -xhd1 /var/log | sort -h

# 큰 파일 상위 20개
sudo find /var -xdev -type f -size +200M -printf '%s %p\n' | sort -n | tail -20

6-3) 파일시스템 예약 블록(특히 ext4)

ext 계열은 root용으로 일정 비율을 예약합니다. 일반 계정으로 보면 “남은 것 같은데” 실제로는 거의 꽉 찬 것처럼 보일 수 있습니다.

# ext4 예약 블록 확인
sudo tune2fs -l /dev/sdXN | grep -E 'Block count|Reserved block count|Reserved block percentage'

운영 정책상 필요하면 예약 비율을 조정할 수 있지만(예: 데이터 디스크), 루트 파일시스템에서 무작정 낮추는 것은 권장하지 않습니다.

7) 실전 복구 플로우(안전한 순서)

장애 상황에서 “일단 지우자”는 접근은 2차 문제를 만들기 쉽습니다. 아래 순서를 추천합니다.

7-1) 어떤 파일시스템이 찼는지 확정

df -hT

7-2) df vs du 비교로 방향 결정

# 예: /var가 의심되면
sudo du -xhd1 /var | sort -h
  • du가 작으면 → 열린 삭제 파일(lsof +L1)
  • du가 크면 → 큰 파일 찾기(find), 로그/도커/캐시 정리

7-3) 열린 삭제 파일 정리

sudo lsof +L1 /var | sort -k7 -h | tail -20
# 해당 서비스 재시작

7-4) inode 확인

df -ih

7-5) 재발 방지(상한/로테이션/모니터링)

  • journald 상한 설정
  • logrotate 점검
  • 도커 이미지/볼륨 정리 정책
  • 디스크 사용량 알람(예: 80/90/95%)

8) 체크리스트 요약

  • df -h는 안 줄고 du만 줄었다 → 삭제된 파일을 프로세스가 잡는 중 (lsof +L1)
  • “용량 남는데도 공간 없음” → inode 고갈 (df -ih)
  • 컨테이너 환경 → /var/lib/docker, overlay2, ephemeral storage 의심
  • 마운트/경로 착각 방지 → findmnt, df -hT로 파일시스템 경계 확인

디스크 100%는 단순한 용량 문제가 아니라, 파일시스템과 런타임(서비스/컨테이너)의 상호작용 문제인 경우가 많습니다. 위 진단 순서대로 보면 대부분은 재시작 1회 또는 정책 수정 1번으로 깔끔하게 해결됩니다.

Discuss on Twitter • View on GitHub