요약: 이를 수행할 수 있는 도구가 있지만 공식 도구 모음의 일부가 아니며 배포 저장소에 없을 수도 있습니다. 다양한 도구 중에서 선택하고 직접 구축해야 할 수도 있습니다. 자세한 내용은 아래를 참조하세요.

도구

btrfs 위키에는 다음과 같은 기사가 있습니다.중복 제거, 여기에는 일부 도구도 언급되어 있습니다.

더 많은 도구가 있습니다. 그 중 하나를 살펴보았는데, 글을 쓰는 시점에서 6년 동안 유지되지 않은 것으로 보이므로 btrfs 위키에 있는 도구를 사용하기로 결정했습니다.

현재로서는 이것들은 공식 btrfs 제품군의 일부가 아니며 적어도 Ubuntu 20.04는 이에 대한 패키지를 제공하지 않습니다. 직접 빌드해야 합니다.

dduper유망해 보입니다. 파일 및 블록 기반 중복 제거를 수행한다고 주장합니다(즉, 전체 파일은 물론 두 개 이상의 파일 사이의 동일한 블록을 중복 제거할 수 있음). 또한 내부 btrfs 인덱싱에 의존하기 때문에 빠르다고 합니다. Python으로 작성되었으므로 사용하기 전에 빌드할 필요가 없습니다( prettytable단, 컴퓨터에 Python 패키지가 필요합니다). 그러나 4KB 미만의 파일은 건너뛰는 것 같습니다. 이는 동일한 작은 파일이 많으면 비생산적이라고 생각합니다.

나는 가기로 결정했다duperemove, 파일 기반 중복 제거만 수행합니다. C 빌드 환경 및 자동화 도구 외에도 libsqlite3-dev컴퓨터에 이 패키지가 필요합니다. 소스 코드를 가져오고 make소스 디렉터리에서 실행하여 빌드합니다. 그런 다음 시스템에 임의의 항목을 추가하고 duperemove싶지 않은 사용자를 위해 소스 디렉터리에서 직접 실행할 수 있습니다 .make install

달리기duperemove

이것문서두 가지 실행 방법이 언급되어 있습니다 duperemove. 직접 실행하거나 fdupes출력을 duperemove. 그러나 2~3TB 데이터 세트와 약 400만 개의 파일의 경우 두 번째는 매우 리소스 집약적인 것으로 나타났습니다(하루 후 진행률은 약 0.5%였으며 지속적인 스와핑과 함께 메모리 사용으로 인해 시스템 성능 저하가 발생함). 거의 사용할 수 없습니다.

나에게 효과가 있는 것 같은 것은

sudo duperemove -drA /foo --hashfile=/path/to/duperemove.hashfile

이는 다음을 수행합니다.

• 내 계정은 디스크의 모든 항목에 액세스할 수 없으므로 전체 프로세스를 루트로 실행하세요.
• -d단순히 해시를 수집하고 중복 목록을 출력하는 대신 결과를 중복 제거( )합니다.
• 주어진 경로의 하위 디렉터리로 재귀( -r)
• 중복 제거를 위해 파일을 읽기 전용으로 엽니다( -A내 스냅샷이 읽기 전용이므로 필요함)
• 해시를 메모리( ) 대신 파일에 저장하면 --hashfile두 가지 이점이 있습니다.
  • 해시 파일이 그대로 유지되는 한 프로세스는 언제든지 중단되었다가 나중에 재개될 수 있습니다.
  • fdupes해시 파일은 디스크 공간(블록당 90바이트, 파일당 270바이트)을 차지하지만 프로세스는 모드에서 실행되는 것과 달리 시스템 메모리를 차지하지 않습니다.

duperemove여러 단계로 실행:

• 인덱스 디스크 내용(즉, 해시 파일에 저장된 내용)
• 중복 해시를 메모리에 로드
• 중복 파일 제거

duperemove인덱스 데이터베이스가 변경되지 않은 한 언제든지 중단하고 재개할 수 있습니다.

시험 결과

제가 실행 중인 디스크 duperemove에는 8개의 하위 볼륨이 있으며, 그 중 5개는 주기적으로 스냅샷이 생성되고 24개의 스냅샷(지난 12개의 월간 스냅샷, 5개의 주간 스냅샷, 7개의 일일 스냅샷)을 보관합니다. 스냅샷을 포함하면 디스크에 약 500만~600만 개의 파일을 저장할 수 있으며, 3.5TB를 차지합니다(중복 제거 전, 중복 제거 후 약 1.8TB).

실행이 시작되고 진행률이 표시 되면 duperemove백분율은 전체 중복 제거 프로세스가 아닌 인덱싱 단계만을 나타냅니다. 중복 해시를 로드하는 것은 확인된 블록 수에 따라 이보다 훨씬 적거나 많을 수 있습니다. 중복 제거에는 인덱싱과 거의 같은 시간이 소요됩니다. 또한 인덱싱 단계의 진행률 계산은 블록 수가 아닌 파일 수만을 기반으로 하는 것으로 보이므로 모든 대용량 파일이 처음에 있는 경향이 있는 경우 필요한 총 시간/공간을 나타내는 신뢰할 수 없는 지표가 됩니다. (또는 끝) 파일의. 에피소드.

중복 데이터를 로드하면 사용 가능한 메모리가 소모될 수 있지만 인덱싱 단계 중 리소스 사용량은 해시된 파일로 작업할 때 시스템의 응답성을 유지할 만큼 충분히 낮습니다. 인덱스 데이터베이스가 시스템에서 사용 가능한 메모리 양보다 크면 과도한 스왑이 발생하여 시스템 속도가 느려질 수 있습니다.

모든 항목(기본 블록 크기 128K)을 색인화하는 데 약 28일이 걸렸으며 21GB 해시 파일이 생성되었습니다. 36일째에 메모리가 부족하여 시스템이 응답하지 않게 되어 중단해야 했습니다. duperemove4일 동안 프로세스의 메모리 사용량은 12~14GB 정도 변동했지만 시스템을 사용할 수 없게 될 때까지 총 메모리 사용량은 계속 증가했습니다.

다음 시도에서는 하위 볼륨을 하나씩 중복 제거하고 데이터가 이동된 것으로 알고 있는 두 하위 볼륨의 부분 사이를 다시 실행하기로 결정했습니다. 나는 1024K 블록 크기로 시작했지만 더 나은 성능을 위해 더 작은 중복 블록과 블록 크기보다 작은 파일을 놓쳤습니다. 이 작업은 약 24시간이 걸렸고 결국 내 드라이브에 약 45GB의 여유 공간이 생겼습니다. 성능은 만족스럽지만 예상했던 공간 절약은 아니었습니다.

300G 하위 볼륨에서 4K를 사용한 또 다른 시도를 중단했습니다. 인덱스는 1024K보다 약 4배나 걸렸지만 3일 후에도 중복 해시 로드가 완료되지 않았습니다. 또 다른 64K 시도가 4시간 만에 완료되었습니다. 작은 청크만 중복 제거하면 되므로 첫 번째 패스 이후 후속 패스의 중복 제거는 더 빨리 완료되어야 합니다.

따라서 실제 경험을 바탕으로 제 조언은 다음과 같습니다.

• 해시 파일 배치가 중요합니다.
  • 디스크 공간이 충분한지 확인하세요(공간이 없어서 중단하고 파일을 이동한 후 다시 시작해야 했습니다).
  • /tmp재부팅 시 지워질 수 있으므로 아마도 좋은 생각은 아닐 것입니다(재부팅할 계획이 없더라도 시스템 충돌이나 정전이 발생하더라도 안전할 수 있습니다).
  • 홈 디렉토리를 암호화했다면 제가 관찰한 것보다 성능이 저하될 것입니다. 내 경험상 외장 USB 디스크의 성능은 내장 HD의 암호화된 홈 디렉토리보다 나은 것 같습니다.
• 두 개 이상의 읽기 전용 하위 볼륨 간에는 데이터 중복을 제거할 수 없습니다. 동일한 하위 볼륨에 읽기 전용 스냅샷이 여러 개 있는 경우 이러한 스냅샷 중 하나만(일반적으로 가장 최근 스냅샷이거나 가장 오래 보관하려는 스냅샷)만 검사되도록 경로를 선택합니다. 현재 세트의 일부 파일이 최신 스냅샷이 아닌 이전 스냅샷과 일치하지 않는 한, 모든 스냅샷을 검색하는 데는 시간이 더 오래 걸리고 더 효율적이지 않습니다.
• 부분 중복 제거 – 파일 시스템을 여러 부분으로 분할하여 사이에 중복된 데이터가 많이 없도록 합니다. 이렇게 하면 중복 해시를 로드할 때 공간이 절약됩니다.
• 다음에 설명된 대로 최적의 블록 크기를 결정합니다.duperemove에 대한 올바른 블록 크기 선택. 내 드라이브의 경우 16K는 0.6~1TB(중복 제거 전) 부분에서는 제대로 작동한 반면, 8K에서는 중복 해시 로드가 몇 시간에서 2일 이상으로 늘어났습니다. 즉, 16K가 제가 사용해 온 최고의 옵션입니다. 작은 부품의 경우 4K가 잘 작동합니다.