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