파티션 수준 중복 제거

블록 수준 중복 제거가 발전함에 따라 현재로서는 ZFS가 최고의 구현이라고 생각합니다. 중복 제거(켜져 있는 경우)는 읽기/쓰기 기능에 직접 내장되므로 실제로 사후 최적화를 위해 설계되지 않았습니다. 따라서 중복 제거 테이블의 가장 관련성이 높은 부분을 메모리에 유지하려고 시도하는 동안 로드 시 일부 메모리를 차지할 수 있지만 ZFS는 설치된 메모리 양에 따라 메모리의 50% 이하로 소비하도록 제한하는 데 능숙합니다. 꽤 임의적으로 보입니다(2Gb의 50% 대 64Gb의 50%, 특히 메모리가 필요한 사용자 작업이 거의 없는 경우).

사용하려는 용도에 따라 몇 가지 옵션이 있습니다.

인디애나 오픈Solaris를 기반으로 하는 몇 가지 좋은 데스크탑 및 서버 옵션이 있는 것 같습니다.

FreeBSD(9.0 기준)에는 상당히 고급 버전의 ZFS가 내장되어 있습니다(중복 제거 포함). 주목할만한 FreeBSD(그리고 MonoWall) 파생 배포판은 다음과 같습니다.NAS4 무료, NAS를 매우 쉽게 만들 수 있습니다.

Linux에는 여러 가지 옵션이 있으며 일부는 중복 제거 기능이 있고 일부는 중복 제거 기능이 없습니다. 중복 제거를 찾고 계신데 제가 본 것 중 가장 주목할 만한 것은zfsonlinux. 얼마나 진행되고 있는지, 프로젝트가 얼마나 안정적인지는 잘 모르겠지만 확실히 유망해 보입니다.

부분 블록 중복 제거 기능이 있는 항목에 대해서는 지금까지 이를 수행할 수 있는 기능이 있다고 보고된 항목을 본 적이 없습니다.

귀하의 질문은 디스크 및 파일 시스템과 관련하여 매우 과부하된 단어인 "블록"이라는 용어 때문에 약간 혼란스럽습니다. (그러나 주변 상황을 명확히 하는 데 도움이 됩니다.) Btrfs는 고정 크기 파일 시스템 "블록"을 처리하지 않고 가변 크기 "범위"를 처리합니다. (혼란스러울 수도 있지만 가변 크기 블록 영역도 정의합니다.) ZFS는 부분적으로 또는 주로 파일 시스템 "블록"을 처리합니다. 이렇게 하면 문제를 훨씬 더 쉽게 해결할 수 있기 때문입니다. Btrfs와 ZFS는 모두 그 자체로 추상화된 디스크 수준 "블록"을 인식합니다. (그리고 "블록 수준 저장소"도 있는데, 이는 의미상 다른 의미를 가질 수 있습니다.) 제가 설명하는 이러한 설명은 약간 다를 수도 있고, 충분히 명확하지 않거나 100% 정확하지 않을 수도 있습니다. (블록 주제에 대해 명확성과 100% 정확성이 필요하다면 읽지 않은 척하십시오. 계속 진행하기 위해 대략적인 이해만 필요하다면 계속 진행하는 것이 좋습니다.) 이 답변의 요점은 정의하는 것이 아닙니다. 완벽함 "블록"이지만 아래 논의는 내 조타실에 더 가깝습니다.

@killermist가 쓴 것처럼 ZFS는 기본적으로 [ZFS] 블록 수준 중복 제거를 지원합니다.

ZFS에서는 기본적으로 활성화되어 있지 않습니다. 메모리가 충분하지 않은 상태에서 열면 성능에 심각한 영향을 미칠 수 있습니다. 또한 ZFS는 전체 해시 테이블을 RAM에 맞추려면 "스토리지 1TB당 RAM 1GB"라는 권장 경험 법칙보다 더 많은 것을 요구한다는 소문이 있습니다. 그러나 그럼에도 불구하고 하드웨어에 따라 최대 40MB/s의 쓰기 속도를 얻을 수 있습니다. ~2015년 시대 드라이브를 실행하는 2008년 시대 기술에서 이것을 얻었습니다. 대부분의 보관 데이터에 대해서는 전혀 문제가 없습니다. ZFS 중복 제거의 가장 큰 단점은 중복 제거를 활성화하는 것 외에도 모든 것을 동일한 파일 시스템의 새 임시 디렉터리에 복사하고 원래 디렉터리를 삭제한 다음 (현재 중복 제거된) 임시 콘텐츠를 다시 그곳으로 이동한다는 것입니다. (오래된 파일을 삭제하는 것을 제외하면 초기 복사/중복 제거 작업보다 시간이 더 오래 걸릴 수 있습니다.) 일반적으로 제가 하는 일은 기본 레이아웃을 변경하기 위해 정기적으로 어레이를 재구축해야 할 때까지 기다린 다음 이전 어레이에서 활성화된 새 어레이로 복사하는 것입니다. 데이터 중복 제거.

Btrfs 중복 제거는 다소 개략적일 수 있으며 현재는 타사 유틸리티만 해당 작업을 수행할 수 있습니다. (그러나 그들은 잘 지원되는 커널 API 및/또는 잘 지원되는 cp 옵션을 사용하며 어느 쪽이든 중복을 결정하기 위한 자체 논리가 필요하며 이는 완전히 정확하기를 바랍니다.) 그러나 잠재적인 이점은 다음과 같습니다. 유틸리티가 "대역 외" 상태입니다. 그러나 대부분의 유틸리티 비용은 망치질 과정에서 성능을 희생한다는 것입니다. 이를 완료하는 데 몇 시간, 며칠 또는 몇 주가 걸릴 수 있습니다. (개인적으로는 1년에 한 번씩 며칠 동안 HDD를 망치는 것보다 대역 내 ZFS 중복 제거를 통해 지속적으로 느린 쓰기 성능을 처리하는 편이 낫습니다.)

나는 파일 대신 "청크"(그러나 다른 정의에서는)를 처리하는 두 가지 Btrfs 솔루션을 알고 있습니다.벌, 그리고두푸.

예를 들어, Bee는 사용 가능한 메모리 및 기타 요인을 기반으로 첫 번째 실행 시 자체적으로 "청크" 크기를 임의로 정의합니다. (저는 이 제품을 사용하지 않고 최근에야 옵션으로 평가했기 때문에 목적, 기능, 메커니즘, 장단점을 잘못 표현했을 수도 있습니다.)

Bees는 기술적으로 ZFS 중복 제거만큼 "대역 내"는 아니지만 지속적으로 실행되고 디스크에 큰 영향을 주지 않도록 설계되었다는 점에서 약간의 하이브리드라고 할 수 있습니다. 사실 이후에 중복 항목을 선택하고 원터치로 제거하려고 시도합니다. 임의로 정의된 블록 크기를 사용한다는 것은 설계상 RAM의 해시 테이블에 적합하다는 것을 의미합니다. (아마도) 단점은 동일한 범위가 "청크"에 존재할 수 있지만 꿀벌이 속한 "청크"가 다르기 때문에 꿀벌이 이를 중복 제거하지 못할 수 있다는 것입니다.

"파일" 수준 Btrfs 중복 제거를 특별히 수행하는 유틸리티(예:침대 라이닝,Dupuy가 삭제되었습니다.,린트등), 여전히 귀하의 요구 사항을 충족할 수 있습니다. 확실히 말할 수는 없지만 그럴 것 같습니다. 이는 "cp --reflink=always" 명령으로도 실제로 "파일"을 중복 제거할 수 없기 때문입니다. Btrfs를 중복 제거하는 중입니다.범위. 다시 연결된 "파일"이 변경되면 Btrfs는 변경된 범위를 고유한 범위로만 중복 제거합니다. 파일의 나머지 부분은 여전히 ​​중복 제거되어 있습니다. 중복 제거된 대용량 파일이 여전히 고유한 파일처럼 분산되어 있지만 대부분은 중복 제거된 상태입니다.

(이것이 "파일"이 다시 링크되었는지 판단하는 것이 그토록 어려운 이유이기도 합니다. 개념 자체가 실제로 이해가 되지 않기 때문입니다. 파일의 모든 내용범위잠재적으로 다른 동일한 범위에 다시 연결된다는 개념은 의미가 있지만 공교롭게도 대답하기가 특히 어려운 질문입니다. 그렇기 때문에 Btrfs 중복 제거 유틸리티가 중복 제거된 내용을 추적하지 않는 한 파일의 중복 제거 여부를 "감지"할 가치가 없습니다. 확인할 참조 횟수와 같은 속성은 없습니다. 어쨌든 중복 항목을 다시 제거하는 것이 더 쉬울 것입니다. 이에 비해 전체 파일이 기존 방식으로 하드링크되었는지 확인하는 것은 쉽지 않습니다. 주어진 inode에 대한 st_nlink 수를 확인하십시오. )

실제로 "전체 파일 복제"가 없다는 점은 Btrfs 범위, ZFS 블록 등을 처리하든 상관없이 "무료" 스냅샷 및/또는 중복 제거를 지원하는 모든 CoW 파일 시스템에 내재되어 있습니다. 이것이 바로 이들 중 하나가 귀하의 질문에 답할 수 있는 이유입니다. (내가 아는 한, 이 모든 것을 할 수 있거나 할 수 있을 예정인 CoW 파일 시스템은 nilfs2, bcachefs, xfs 세 개 이상 있습니다.)

언급하지는 않았지만 제가 아는 한 파일 형식을 인식하는 중복 제거 기술은 없습니다. 즉, 어떤 중복 제거 장치도 *.jpg 메타데이터를 건너뛰고 중복 제거를 위해 압축된 이미지 데이터만 고려하는 방법을 모릅니다. 다시 말하지만, 그 중 어느 것도 파일 매직 넘버(적어도 중복 제거를 결정할 때 고려해야 할 사항)를 고려하지 않습니다. 이는 킬러 기능이 될 수 있습니다. 물론 지속적이고 지속적인 정의 업데이트가 필요하기는 하지만 말입니다. 그리고 파일을 범위, 블록 등의 추상적인 M:M 컬렉션으로 생각하면 디자인하기가 매우 어려울 수 있습니다.