du매시간 여러 개의 큰 폴더(총 10-20TB 파일, #개 파일은 100,000개 미만)에서 실행되도록 cron을 예약하는 것의 영향을 분석하고 있습니다 .
내가 이해한 바로는 RAM에 캐시된 inode 정보를 읽는 du용도입니다 . stats이 올바른지? 아니면 디스크 캐시인가요? 아니면 둘다?
위의 내용이 맞다면 자주 실행하면 다음과 같은 효과가 있다고 가정할 수 있습니까 du?
- 내 시스템 성능에 부정적인 영향을 미치지 않으며
- 스핀들에 불필요한 마모가 발생하지 않습니까?논쟁거리가 될 수도 있지만 그냥 유머러스하게 해주세요
출력 에 대한 일종의 캐싱을 제공하는 여러 도구를 읽었 du지만 내 목표는 차이점을 파악하여 토론과 관련이 있는지 확신하지 못하는 것입니다.
정말 감사합니다!
답변1
내가 이해한 바에 따르면 du는 RAM에 캐시된 inode 정보를 읽는 통계를 사용합니다. 이 올바른지? 아니면 디스크 캐시인가요? 아니면 둘다?
"RAM에 캐시됨": 예, 어느 정도 그렇습니다. 완전하지는 않습니다. 파일 시스템 버퍼도 RAM을 먹고 100,000개의 inode/범위 목록에도 RAM이 필요하므로 "둘 다"입니다. ("디스크 캐시"는 거의 의미가 없습니다. 데이터 구조가 디스크에 있으므로 캐시가 아니고 기본 데이터입니다.)
위의 내용이 정확하다면 du를 자주 실행하면 다음과 같이 될 것이라고 가정할 수 있습니다.
- 내 시스템 성능에 부정적인 영향을 미치지 않으며
당신은 그것을 가정할 수 없습니다. 전체 파일 시스템이 RAM에 있더라도 이는 여전히 데이터 집약적 작업이므로 CPU와 RAM 및 드라이브 인터페이스 대역폭을 모두 사용하게 됩니다.
스핀들에 불필요한 마모가 발생하지 않습니까? 논쟁의 여지가 있을 수도 있지만 그냥 유머러스하게 해주세요
저는 스핀들 마모를 본 적이 없습니다. 그럼, 음, 그렇죠? 또한 하드 드라이브를 사용하는 동안 회전하기 때문에 이 질문이 제대로 고려되었는지 확실하지 않습니다!
du 출력에 대해 일종의 캐싱을 제공하는 여러 도구를 읽었지만 내 목표는 차이점을 파악하여 토론과 관련이 있는지 확신하지 못하는 것입니다.
변화를 추구한다면 아마도 거꾸로 접근하고 있을 것입니다. du아마도~ 아니다그렇다면 선택한 도구!
- 실제로 inotify를 사용하여 파일 속성의 변경 사항에 대한 알림을 받을 수 있습니다. 단지 몇 가지 변경 사항을 얻기 위해 전체 파일 시스템을 탐색하는 것보다 부하가 적습니다!
dubtrfs에서사용된 스토리지에 대해 속일 것입니다. Btrfs는 스마트합니다. 복사된 파일은 쓰기 전까지 추가 스토리지가 필요하지 않으며, 스파스 파일 영역도 필요하지 않습니다. 스냅샷 및 하위 볼륨 개념으로 인해 이 모든 것이 개념적으로 조금 어려워집니다.du모든 파일 크기를 합산하면 됩니다. 동일하지 않음디스크 사용량!
해결하려는 문제를 du자세히 설명하고 현재 접근 방식을 설명하는 새 질문(댓글이 아닌 새 게시물)을 물어볼 것을 제안합니다. 여기서 귀하의 질문은 매우 구체적인 접근 방식의 작은 측면에 대해 묻는 것 같으며 이 접근 방식이 실제 문제를 해결하는지 잘 모르겠습니다!