FUSE 파일 시스템에 새로운 5TB 디스크가 있는데 기본적으로 비어 있는 것 같지만 df는 그렇지 않다고 말합니다. 디스크의 파일 시스템은 mergerfs
4개의 5TB Seagate 5400rpm 외장 하드 드라이브로 구성되며 모두 1개의 파티션으로 ext4
포맷 되었습니다 fdisk
. 루트로 들어가서 du로 확인해 보니 약 500GB의 공간이 사용되었다고 합니다.
pi@raspberrypi:~ $ df -h /mnt/hdd/disk4
Filesystem Size Used Avail Use% Mounted on
/dev/sdb1 4.6T 4.3T 393M 100% /mnt/hdd/disk4
root@raspberrypi:~# du -sh /mnt/hdd/disk4
464G /mnt/hdd/disk4
누구든지 이 문제를 해결하도록 도와줄 수 있나요?
답변1
이것은 제가 이전에 겪은 일이지만, 제 경험으로는 극단적인 경우입니다. 이는 일반적으로 디스크에서 삭제된 파일이 있어서 du
보고되지는 않지만 실행 중인 프로세스 어딘가에 아직 열려 있는 경우 에 발생하므로 df
사용되는 공간을 고려하십시오. 가장 일반적인 "범인"은 logrotate가 로깅 프로세스를 제대로 다시 시작하지 않아서 다음과 같은 결과를 초래하는 것입니다.
- 디스크에 표시되는 로그 파일은 기록될 수도 있고 기록되지 않을 수도 있습니다.
- 로그 쓰기 프로세스는 활성 로그 파일(예: )
app.log
과 전날의 로그 파일(예2022-01-03-app.log
: 오늘이 2022-01-04인 경우)에 (아마도) 쓰고 있지만 전날의 파일은 있습니다ls
(예:2022-01-03-app.log.gz
). - 압축을 풀면 전날의 로그 파일이 많은 공간(수십 GB)을 차지합니다.
이 특정 예에서 logrotate
데몬은 자정에 전날의 로그 파일을 회전하고 전날의 타임스탬프를 제공하지만 프로세스에 기록하여 실제로 로그 다시 시작을 트리거하지는 않습니다. 전날의 로그 파일을 압축한 후 압축되지 않은 파일을 삭제하지만, 쓰기 과정에서 여전히 파일 핸들이 열려 있으므로 df
공간이 이미 점유된 것으로 간주합니다.
이 문제는 일반적으로 logrotate 구성 파일에 (SIGHUP) 유형 지시문을 추가하여 해결할 수 있지만 HUP
, 드문 경우지만 HUP에 올바르게 응답하지 않기 때문에 문제가 있는 프로세스를 실제로 다시 시작해야 합니다.
이러한 경우 문제가 되는 프로세스를 찾아 다시 시작하면 보고된 사용 공간이 df
갑자기 급격하게 줄어들고 df
출력이 du
일치하게 됩니다.