디렉터리의 보고서 콘텐츠가 조각화되어 있더라도 다른 곳에 존재합니다.

전체 콘텐츠가 다른 곳에 존재한다는 것을 알고 있기 때문에 (빠른 수동 확인이 필요한 경우에도) 삭제해도 안전하다고 알고 있는 디렉터리에 대한 보고서를 생성하고 싶습니다.특히 중복 파일이 볼륨의 다른 위치, 완전히 다른 디렉터리 레이아웃 및 관련 디렉터리에 존재하지 않는 파일 사이에 무작위로 흩어져 있는 경우에도 마찬가지입니다.

즉, 디렉터리 구조와 내용이 동일하지 않습니다. 그러나 100% 포함된 파일은 동일한 FS의 어느 위치에나 별도로 복사됩니다.

아래의 워크플로와 사용 사례를 보면 이것이 거의 항상 단방향 관계라는 것이 분명해집니다. dir1의 파일 내용은 100% 다른 파일 이름과 디렉터리 구조로 다른 곳에 존재할 수 있으며, 종종 각 파일의 여러 복사본이 있을 수 있습니다.

예를 들어 dir1/file1의 복사본이 dir2 및 dir3에 존재할 수 있습니다. dir1/file2의 복사본이 dir2 및 dir4에 있을 수 있습니다. dir2, dir3 및/또는 dir4에는 고유한 파일은 물론 다른 디렉터리에 있는 파일 복사본도 포함될 수 있습니다. 그러나 dir1은 삭제해도 안전합니다.

즉, 역상관이 없습니다. dir1은 100% 중복 분산을 갖지만 dir2, dir3, dir4... 등은 있습니다. 반드시 그런 것은 아닙니다. (그들 자체가 삭제 후보일 수도 있고 따라서 삭제 후보일 수도 있지만 현재 가장 유력한 후보는 dir1입니다.)

이 질문의 나머지 부분을 이해하고 대답하기 위해 꼭 읽어야 할 필요는 없습니다. 단지 주제에서 벗어난 "왜?"와 "... 시도해 보셨나요?"라는 질문에 답할 뿐입니다.

이는 실제로 상당히 흔한(또는 적어도 드물지 않은) 것처럼 보이는 요구사항 생성에 대한 사용 사례입니다. ...최소한 최종 결과는 다릅니다.

1. 장소:
   1. GB의 사진과 영상을 찍었습니다.
   2. 매일 저는 메모리 카드의 파일을 카메라 이름과 날짜별로 정리된 폴더로 옮긴 다음 중복 배열의 휴대용 USB HDD로 옮깁니다.
   3. 시간되면 정리하겠습니다복사파일 이름 앞에 "yyyymmdd-hhmmss"가 붙은 "(photo|video)/year/date"와 같은 폴더 구조에 파일을 넣습니다. (즉, 원래 구조가 완전히 뒤섞여 있습니다. 그리고 항상 예측 가능한 방식은 아닙니다.) 이러한 정리된 복사본은 빠른 작업 흐름을 위해 SSD 드라이브에 있지만 관리되지 않는 원본 복제본은 백업 목적으로 느린 중복 스토리지에 유지합니다. , 복제 단계와 별도로 복제본은 물리적으로 분리됩니다.
2. 집으로 돌아가:
   1. 내 작업 흐름에 문제가 있을 경우를 대비해 관리되지 않는 모든 파일을 USB HDD 어레이에서 "영구"(더 크고 강력하며 지속적인 클라우드 백업) 어레이로 옮겼습니다.
   2. SSD에서 정리된 복사본을 사후 처리합니다. (이름 변경을 제외하고 원본 원본 파일을 그대로 유지하고 변경 사항을 새 파일에 저장하십시오.
   3. 작업을 마치고 원하는 결과를 얻으면 전체 SSD 파일 구조를 원본 파일과 동일한 더 큰 "영구" 배열로 옮깁니다. (단, 디렉터리 구조는 원래 SD 카드 덤프 구조와 전혀 다르다는 점을 명심하세요.)

이상적으로는 이 작업 흐름에서는 더 이상 필요하지 않은 원본 카드 덤프 폴더도 삭제합니다. 문제는 인생에서와 마찬가지로 작업 흐름이 계속 중단된다는 것입니다. 현장에서 정리할 시간이 없거나, 집에 돌아와서 잠시 따로 치워두거나, 매번 똑같은 방식으로 정리하지 않거나, 아니면 어디에 있는지 헷갈릴 뿐입니다. 그리고 거기에 무엇이 있고 아무것도 삭제하는 것을 두려워합니다. 일반적으로 나가기 전에 휴대용 미디어가 2~3번 거기에 있었던 것으로 의심되더라도 만일의 경우를 대비하여 영구 어레이에 복사합니다. (저는 OCD가 아닙니다. 단지 경험으로 인해 상처를 입었을 뿐입니다.) 때때로(나중에는 덜 자주) 전체 논리적 디렉토리 구조를 재구성할 것입니다. 다른 경우에는 스트림 중간에 업데이트하고 이전 콘텐츠를 무시합니다. 나는 또한 수년에 걸쳐 장소를 옮겼으며 "카드 덤프" 파일이 어디로 (그리고 어떻게) 갔는지 전혀 모릅니다. 때때로 내 라이브 작업 흐름은 잘 정의되고 테스트되었음에도 불구하고 다양한 폴더가 불확실한 상태로 남아 있는 결과를 가져오기 때문에 "만일의 경우"에 대비하여 더 많은 백업 복사본을 만듭니다. 나는 또한 나의 거대한 폴더 구조를 다양한 방식으로 보기 위해 수천 개의 폴더 심볼릭 링크를 생성할 수 있는 프로그램을 작성했습니다. (파일 시스템 "피벗 테이블"과 같습니다.) 그러나 "하드 링크 및 심볼릭 링크 보존" 플래그 설정을 잊어버린 채 전체 파일 시스템을 교체 배열에 동기화하면 이전에 링크였던 것의 복사본이 생성됩니다. 그러다가 시간이 지나면 어느 것이 진짜 원본인지 더 이상 알 수 없게 됩니다. (더 나은 결과를 얻으려면 20년간의 사진/동영상과 30년간의 추가 데이터를 함께 사용해 보세요!)

즉, 나는 도처에 수백만 개의 대용량 파일을 가지고 있으며, 그 중 대부분은 불필요하게 중복되고 복잡합니다. 나는 그것을 고쳐야한다. 공간을 절약할 뿐만 아니라(이미 처리된) 안전한(그리고 더 중요하게는 표준적인) 위치의 혼란을 줄이기 위한 것입니다. 저의 경우 첫 번째 단계는 콘텐츠가 다른 곳에 배포되었다고 100% 확신하는(반드시 확신할 수는 없음) 수천 개의 폴더를 삭제하는 것이었습니다. 각 삭제 후보도 빠른 수동 확인이 필요합니다.

인간이 평생 동안 할 수 없는 초기 목록을 생성하는 것입니다. 이상적으로 목록은 "이 디렉터리의 모든 파일은 다른 곳에 있지만 다른 디렉터리 레이아웃에 있으며 이러한 디렉터리에도 일치하지 않는 파일이 포함되어 있습니다"입니다. 하지만 적어도,"이 디렉터리의 모든 파일은 다른 곳에도 존재합니다.".

저는 약 12개의 중복 제거 솔루션을 연구하고 테스트했는데 그 중 일부는 문제 해결에 매우 근접했지만 충분히 근접하지는 않았습니다. 내 "영구" 어레이에는 수년 동안 인라인 ZFS 중복 제거가 활성화되어 있었습니다. 쓰기 처리량이 약 25%로 줄어들지만 기다릴 수는 있지만 수십 년에 걸쳐 사진을 두 번, 심지어 세 번 복제하는 데 필요한 수천 달러의 추가 드라이브 공간과 비디오 데이터를 감당할 수 없습니다. -웨이 미러 스트립).

방금 로컬 자동 백업 어레이를 구성했습니다(클라우드 백업을 보완하기 위해). 동일한 스토리지 소프트웨어를 사용하여 동시에 동일한 오류가 발생하는 잠재적인 문제를 피하기 위해 Btrfs RAID1을 선택했습니다. (이전에 ZFS를 사용하여 이 문제를 겪은 적이 있는데 운 좋게도 일시적으로 마운트할 수 없게 되었습니다.) 또한 이 솔루션에는 디스크 어레이를 한 번에 쉽게 확장하거나 축소할 수 있는 멋진 기능이 있습니다. :-) 이는 내 대규모 기본 ZFS 어레이에 대한 비용이 매우 많이 들고 시간이 많이 걸리는 제안이기 때문에 좋습니다.

어쨌든, 이 질문이 관련된 유일한 이유는 Btrfs가 오프라인 중복 제거를 위한 수많은 훌륭한 유틸리티를 가지고 있다는 것입니다. 제가 말했듯이 그 중 일부는 문제 해결에 매우 가깝지만 충분하지 않습니다. 내가 시도한 내용을 간단히 요약하면 다음과 같습니다.

• 찾다: 빠른 매칭 알고리즘으로 하드 링크를 통한 중복 제거에 이상적입니다. 문제는 이것이 모든 사용자(모든 사용자?)에게 재앙을 초래할 수 있다는 것입니다. 이름이나 위치에 관계없이 크고 중복되는 미디어 파일 사이의 공간을 절약해야 한다는 명백한 독립 실행형 요구 사항에 대해 부분적으로 작동하는 반면, 쉽게 해결할 수 없는 다른 문제에는 재앙이 되는 것으로 나타났습니다. 예를 들어, 관계가 없는 다른 동일한 파일을 함께 하드 링크하기도 합니다. 예를 들어, 운영 체제와 애플리케이션에 의해 자동으로 생성되는 다양한 메타데이터 파일이 있으며, 그 중 대부분은 수백 또는 수천 개의 디렉터리에서 동일하지만 반드시 다를 수 있어야 합니다. 예를 들어 "Thumbs.db"와 같은 파일을 참조하면 나중에 데이터 손실이 발생할 수 있으며 이는 사소할 수도 있고 아닐 수도 있습니다. ) 중복된 Btrfs 참조 링크를 제거하는 옵션이 있지만(나중에 CoW와 구별 가능) 이 기능은 "실험적"으로 표시됩니다.
• Dupuy가 삭제되었습니다.: 중복 제거를 위해 Btrfs 참조 링크를 사용하므로 이는 나중에 파일을 분산시키는 동시에 디스크 공간을 절약할 수 있는 허용 가능한(좋은, 균일한) 방법입니다. (현재 Btrfs는 조각 모음을 할 때(커널에 따라 다름) 파일의 중복을 제거하지 않는 것 같습니다. 심지어 스냅샷도 마찬가지입니다. 정말 끔찍한 일이지만 조각 모음을 하지 않고 결과를 받아들이지 않음으로써 이를 방지합니다.) duperemove 문제는 다음과 같습니다. 검색된 모든 파일을 맹목적으로 체크섬하며 매우 느리고 디스크를 오랫동안 소모합니다. 기본적으로 가난한 사람의 배열 정리를 수행합니다. 내 배열은 며칠이 걸립니다. (bedup, bees 및 기타 몇몇은 다른 방식에서는 매우 다르지만 이 점에서는 유사합니다. rdfind 및 기타 몇몇은 더 똑똑합니다. 먼저 파일 크기를 비교합니다. 그 다음 처음 몇 바이트, 그 다음 마지막 몇 바이트만 비교합니다. 모두 일치하면 체크섬에 의존합니까)
• 린트: 이것은 현재 디스크 공간 절약에 대한 다른 요구 사항에 가장 적합한 것 같습니다. 두 가지 Btrfs 재링크 옵션(커널 모드 원자 복제 및 약간 덜 강력한 "cp --reflink" 방법)이 있습니다. 스캔 알고리즘은 제가 테스트한 것 중 가장 빠릅니다. 해싱은 SHA256 이상(비트 포함)으로 향상될 수 있으며 많은 요구 사항을 충족하는 유용한 옵션이 많이 있습니다. (내가 아는 한, 이 질문에 나온 것을 제외하고.)

fdupes, fslint 등을 포함한 다른 많은 중복 제거 유틸리티가 있습니다. 나는 Btrfs 지원이 없더라도 (대부분 이 질문과 관련이 없기 때문에) 그것들을 거의 테스트 (또는 읽었습니다)했습니다. rmlint를 제외하면 그 중 어느 것도 내가 필요한 기능에 근접하지 않습니다.