파일을 지웠는데 디스크가 그대로라면: 열린 파일과 df·du 차이 확인

오래된 로그 파일을 지웠고 디렉터리 목록에서도 사라졌습니다. 그런데 df로 본 디스크 사용량은 거의 줄지 않습니다. 더 지울 파일을 찾기 전에, 파일을 열고 있는 프로세스와 숫자의 집계 범위를 확인할 필요가 있죠.

이번 글은 Linux에서 삭제된 열린 파일을 조사하는 관점을 다룹니다. 명령 예시는 상태 조회용이며 실제 운영 서버에서 실행한 결과나 고객 사례가 아닙니다. df와 du는 GNU 구현을 기준으로 설명하므로 사용 중인 도구의 로컬 매뉴얼도 확인하세요.

파일을 삭제해도 디스크 공간이 남는 이유는 무엇인가요?

파일의 마지막 이름을 지워도 프로세스가 열어 둔 참조가 남아 있으면 파일은 바로 사라지지 않습니다.

Linux unlink 매뉴얼은 파일시스템에서 이름을 제거하는 동작과 파일의 수명이 끝나는 조건을 구분합니다. 마지막 링크가 제거됐더라도 프로세스가 파일을 열고 있다면 마지막 파일 디스크립터가 닫힐 때까지 파일이 남는다고 설명합니다.

여기서 마지막 이름이라는 조건도 중요합니다. 다른 하드 링크가 남아 있는 경우와 이름은 모두 없어졌지만 열린 참조가 남은 경우는 다르죠. 파일 하나를 지웠다는 사실만으로 어떤 상태인지 확정하지 않습니다.

이 때문에 디렉터리를 따라 파일을 집계하는 결과와 파일시스템의 사용량이 다르게 보일 수 있습니다. 다만 모든 차이가 같은 원인이라는 뜻은 아니에요. 먼저 두 도구가 같은 대상을 보고 있는지 확인해야 합니다.

df와 du는 각각 어떤 범위를 계산하나요?

df는 파일시스템의 공간을, du는 지정한 파일과 디렉터리의 사용량을 집계하므로 범위부터 맞춥니다.

GNU df 매뉴얼에 따르면 경로를 인수로 주면 그 경로가 속한 파일시스템의 공간을 보여줍니다. 경로가 /var/log라고 해도 /var/log 디렉터리 안의 파일만 합산한 수치는 아니죠. 해당 경로가 속한 파일시스템 전체를 보는 것입니다.

반면 GNU du 매뉴얼은 지정한 파일 집합과 디렉터리의 재귀 집계를 설명합니다. 하위 디렉터리 하나의 du 합계를 파일시스템 전체의 df 사용량과 바로 비교해 차이를 삭제 파일 크기라고 계산하면 안 됩니다.

/var/log는 실제로 존재하는 점검 경로로 바꿔 사용하는 예시입니다. 비교할 때는 마운트 범위·조회 권한·측정 시점과 단위를 맞추고, du의 집계 옵션도 기록하세요. 디렉터리 순회는 큰 경로에서 시간이 걸릴 수 있으므로 조사 범위를 먼저 정합니다.

du의 --apparent-size는 일반적인 디스크 사용량 집계와 다르고, -x는 다른 파일시스템의 디렉터리를 건너뛰는 옵션입니다. 옵션 하나가 두 도구의 값을 항상 같게 만들어 주지는 않습니다.

lsof +L1은 어떤 파일을 골라 보여주나요?

lsof +L1은 링크 수가 1보다 작은 열린 파일을 골라 삭제 뒤에도 남은 참조를 조사하도록 돕습니다.

lsof 매뉴얼에서 +L 뒤의 수는 그보다 링크 수가 작은 파일을 선택하는 조건입니다. 따라서 lsof +L1은 이름 연결이 제거됐지만 열려 있는 파일을 찾는 데 사용합니다. 파일 삭제나 프로세스 종료 명령은 아닙니다.

결과에서는 프로세스와 파일 식별 정보를 맞춰 보세요. 같은 파일이 여러 프로세스나 파일 디스크립터를 통해 나타날 수 있으므로 행 개수를 파일 개수로 간주하지 않습니다. 조사 대상 파일시스템과 관련 있는지도 함께 확인하죠.

SIZE/OFF는 파일 크기 또는 오프셋을 표시할 수 있는 열입니다. 열의 뜻을 확인하지 않은 채 숫자를 모두 더해 회수 가능한 공간이라고 보고하지 마세요. 실행 권한이나 경고 때문에 확인 범위가 제한됐다면 결과가 없다는 이유로 원인이 없다고 단정하지 않습니다.

열린 파일이 보이면 프로세스를 바로 종료해도 되나요?

열린 파일 목록은 조사 근거이므로 서비스의 기록 보존 조건과 영향을 확인한 뒤 조치 방법을 정합니다.

파일을 열고 있는 주체를 찾았다는 사실과 그 프로세스를 중단해도 된다는 판단은 별개입니다. 먼저 서비스 담당자와 해당 파일의 용도, 필요한 기록 보존, 현재 업무 영향을 확인하세요. 로그 파일처럼 보여도 이미 불필요한 데이터라고 가정하지 않습니다.

일부 서비스에는 로그를 다시 여는 절차가 있지만 모든 서비스가 같은 신호나 reload 동작을 지원하지는 않습니다. 서비스의 공식 운영 문서와 현재 구성을 확인해 적절한 방법을 검토해야 하죠. 강제 종료나 파일 강제 비우기를 공통 처방으로 삼지 않는 이유입니다.

Docker의 로그 파일은 별도 관리 조건도 살펴야 합니다. 도커 로그가 디스크를 채운다면: json-file 용량 제한과 로테이션 확인은 드라이버와 제한 설정을 다룹니다. 여기서는 로테이션 설정을 반복하지 않고 삭제 후 남은 참조의 조사에 집중합니다.

조치 뒤 같은 파일시스템에서 무엇을 다시 확인하나요?

같은 파일시스템과 집계 범위에서 열린 참조·사용량·업무 동작을 다시 확인하고 남은 차이를 기록합니다.

조치 전후에는 대상·조회 시각·집계 옵션을 함께 기록하는 방식을 제안합니다. 열린 참조가 사라졌는지, 파일시스템의 사용량이 어떻게 달라졌는지, 관련 서비스가 정상적으로 기록하고 응답하는지를 나눠 확인하세요.

이 표는 기록 방식의 제안이며 실제 측정값이 아닙니다. 운영 중에는 다른 쓰기 작업도 진행될 수 있어 차이가 예상한 숫자와 정확히 같다고 보장하지 않습니다. 열린 파일을 확인했더라도 모든 용량 차이의 원인을 찾았다고 결론 내리지 마세요.

파일 생성 실패와 inode 고갈을 조사하는 관점은 디스크 여유가 있는데 파일을 못 만든다면: df -h와 df -i를 함께 보는 이유에서 다룹니다. 이번 글은 공간이 반환되지 않는 상황과 열린 참조를 구분하는 데 초점을 둡니다.

이것만 기억하세요

자주 묻는 질문 (FAQ)