.png)
폴더를 탐색하는 동안 ncdu파일의 겉보기 크기가 실제 디스크 사용량보다 훨씬 더 큰 경우가 있음을 발견했습니다. 예제를 살펴본 ncdu후 a디스크 사용량 표시와 명확한 표시 사이를 전환한 다음 i추가 세부정보 표시를 수행합니다.
이는 데이터의 일부만 "빠른" 계층에 유지하고 나머지는 더 느린 위치(예: AWS S3)에 유지하는 일부 자동화된 프로세스 때문일 수 있다는 말을 들었습니다. 어떻게 확인하나요?
~처럼제안통과크리스 탕hexdump, 다음은 해당 파일에서 실행된 부분 출력입니다.
이는 파일이 희소하지 않음을 나타내는 것 같습니다.
~처럼제안통과아르툠 S.타슈키노프, 파일 시스템은광택(확인하는 데 사용 sudo df -T).
답변1
이는 일반적인(그러나 명확하지는 않은) 동작입니다.Lustre와 같은 계층형 스토리지 시스템. ncdu기타 희소 측정 도구는 종종 주어진 값에 의존합니다.st_blocks에 응답하다stat부르다. 기록 중 복사가 아닌 파일 시스템에서 명백한 동작은 우리가 예상하는 것과 같습니다. 각 파일은 디스크에서 포함된 0이 아닌 데이터의 정확한 양을 최소한으로 차지합니다 st_blocks. 파일에 0이 저장되었습니다. Lustre에서는 st_blocks파일에 저장된 데이터의 총량이 아닌 프런트엔드 시스템에서 사용되는 스토리지를 나타냅니다.
단 하나의 작은 예외가 있습니다. "게시된" 파일(내용이 프런트엔드 저장소에서 완전히 삭제됨)은 0이 아닌 512바이트를 차지하는 것으로 표시됩니다. 이것이 달성된다도구 문제에 대한 해결책으로, 예를 들면 다음과 같습니다.tar이렇게 하면 st_blocks0이 있는 파일 읽기를 완전히 건너뛰어 Lustre 기반 파일 시스템에서 데이터 손실이 발생합니다(백업 시나리오에서 흔히 발생하는 스파스 파일 감지를 사용하여 게시된 파일을 보관하면 데이터가 전혀 저장되지 않습니다). 파일이 512바이트를 차지한다고 표시되면 도구는 해당 파일을 읽어야 합니다(또는fiemapioctl 등) 포함된 내용을 정확히 확인하기 위해 Lustre에서 이러한 작업을 수행하면 계층 구조에 저장된 위치에서 파일 데이터를 검색하게 됩니다.
대용량 파일의 경우 전체 파일을 프런트엔드 스토리지에 복원하는 것은 드문 일이며, 이로 인해 일부 "점유된 블록 수"만 표시되는 경우도 있습니다.