이건 그냥 내 댓글이야"du" 다이제스트를 어떻게 캐시하거나 속도를 높일 수 있나요?자체적인 질문으로 공식화됨:
du각 디렉토리의 전체 크기 가 저장되고 "버블링"되는(즉, 모든 상위 디렉토리의 크기가 올바르게 조정되도록 트리 위로 전파되는) 파일 시스템을 만드는 것에 대한 확장된 논의가 있습니까? 등등, 그럼 du이게 즉시 될까요?
위에 링크한 답변을 보면 이렇게 하면 I/O 성능이 저하된다는 것이 분명합니다. 그 영향이 얼마나 클지 궁금합니다. 몇 배나 줄어들까요, 아니면 단지 몇(10% 이상) 정도 줄어들까요?
이와 밀접하게 관련된 것은 동일한 방식으로 mtime을 "버블링"하여 각 디렉토리의 mtime이 전체 하위 트리 내의 최신 변경 사항을 반영하도록 하는 개념입니다. 예를 들어 깊게 중첩된 파일이 많은 트리의 경우 이 두 기능을 함께 사용하면 rsync모드 속도를 크게 높일 수 있습니다.--update
답변1
최신 파일 시스템(예: zfs/btrfs/bcachefs)은 실제로 반대 방향으로 진행되며 파일 간의 공유 범위를 허용/장려합니다. 이러한 방식으로 "디렉토리가 차지하는 데이터의 양"에 대한 개념은 덜 명확해집니다(이는 하드 링크로 인해 이미 어느 정도 사실임에도 불구하고). 참조 링크를 사용하면 분명히 더 많은 데이터를 포함하는 디렉토리를 만들 수 있습니다. 파일 시스템에 적합합니다(적어도 du또는 ncdu이해할 수 있는 간단한 디스크 분석 도구인 경우 ). 질문을 다르게 표현하는 한 가지 방법은 "이 디렉토리가 삭제되면 얼마나 많은 여유 공간이 확보될 것인가"입니다. 이는 덜 모호하지만 스냅샷이 생성되면 대부분의 디렉토리가 이제 고유한 크기 0을 갖기 때문에 별로 유용하지 않습니다. 스냅샷을 통해서도 데이터에 액세스할 수 있습니다.
나는 또한 이 문제에 직면했습니다:
- 데이터 공유가 가능한 파일 시스템에서는 공간 사용량을 파악하기 어렵습니다.
- 대용량 파일 시스템에서 공간 사용량을 분석하는 데 너무 많은 시간이 소요됨(I/O)
이를 위해 나는 창조했다BTDU, btrfs와 관련된 이러한 문제를 해결하는 샘플링된 디스크 사용량 분석기입니다.
일반적인 "버블" 개념에 관해서는 다음과 같습니다. 다른 파일 시스템에 대해서는 잘 모르겠지만 이는 실제로 다른 트리를 재귀적으로 참조하는 탭루트(b-) 트리가 있는 btrfs가 내부적으로 작동하는 방식과 유사합니다. 트리(다양한 수준)가 업데이트되면 새 복사본이 디스크의 다른 곳에 기록되고(따라서 btrfs의 COW 측면) 부모는 새 복사본을 가리키도록 업데이트됩니다. 루트 트리까지. (실제로 이 구현에서는 불변성을 유지하면서 합리적인 성능을 유지하기 위해 많은 최적화를 사용합니다.)