블록 수준 또는 보다 세부적인 중복 제거에 사용할 수 있는 솔루션은 무엇입니까?
"쓰기 시 복사" 접근 방식을 사용하는 파일 기반이 있습니다.
저는 블록 수준 "기록 중 복사"를 찾고 있으므로 주기적으로 공통 블록을 찾거나 파일의 일부를 병합하고 CoW 사용 방식에 대해 플래그를 지정할 수 있습니다. 이와 같은 것을 사용할 수 있습니까, 아니면 여전히 생성해야 합니까? Btrfs 중복 제거가 블록/파일/하위 부분 수준인지 확실하지 않습니까? LessFS가 있지만 이것이 어느 수준의 중복 제거를 제공하는지 잘 모르겠습니다. 어쩌면 다른 해결책일까요?
답변1
블록 수준 중복 제거가 진행됨에 따라 ZFS는 현재 경쟁의 여지가 없는 최고의 구현이라고 생각합니다. 중복 제거(켜져 있는 경우)가 읽기/쓰기 기능에 직접 내장되어 있기 때문에 실제로 사후 최적화를 위해 설계되지 않았습니다. 이로 인해 중복 제거 테이블의 가장 관련성이 높은 부분을 메모리에 유지하려고 하면 로드 시 약간의 메모리 비용이 발생할 수 있지만 ZFS는 메모리의 50% 이하를 소비하도록 제한하는 데 능숙합니다. 설치된 메모리 양은 매우 임의적일 수 있습니다(특히 메모리가 필요한 사용자 작업이 거의 없는 경우 2Gb의 50% 대 64Gb의 50%).
사용하려는 용도에 따라 몇 가지 옵션이 있습니다.
오픈인디애나Solaris 기반의 좋은 데스크탑 및 서버 옵션이 있는 것 같습니다.
FreeBSD(9.0부터)에는 매우 고급 버전의 ZFS(중복 제거 포함)가 내장되어 있습니다. 주목할만한 FreeBSD(당시 MonoWall) 파생 배포판 중 하나는 다음과 같습니다.NAS4무료, NAS를 매우 쉽게 만들 수 있습니다.
Linux에는 몇 가지 옵션이 있는데, 일부는 중복 제거 기능이 있고 일부는 중복 제거 기능이 없습니다. 중복 제거를 찾고 계신데 제가 본 것 중 가장 눈에 띄는 것은zfsonlinux. 그들의 진행 상황이나 프로젝트가 얼마나 안정적인지는 잘 모르겠지만 확실히 유망해 보입니다.
부분 블록 중복 제거 기능이 있는 경우에는 지금까지 해당 기능이 보고된 것을 본 적이 없습니다.
답변2
귀하의 질문은 디스크 및 파일 시스템과 관련하여 매우 과부하된 단어인 "블록"이라는 용어로 인해 약간 혼란스럽습니다. (그러나 주변 상황을 명확히 하는 데 도움이 됩니다.) Btrfs는 고정 크기 파일 시스템 "블록"을 처리하지 않고 가변 크기 "범위"를 처리합니다. (하지만 혼란스럽게도 가변 크기 블록 영역도 정의합니다.) ZFS는 부분적으로 또는 주로 파일 시스템 "블록"을 처리합니다. 이렇게 하면 문제를 훨씬 쉽게 해결할 수 있기 때문입니다. Btrfs와 ZFS는 모두 그 자체가 추상화인 디스크 수준 "블록"을 인식합니다. (그리고 의미상 다른 의미일 수 있는 "블록 수준 저장소"도 있습니다.) 이러한 설명이 약간 잘못되었거나, 충분히 명확하지 않거나, 100% 정확하지 않을 수 있습니다. (블록 주제에 대해 명확성과 100% 정확성이 필요하다면 읽지 않은 척하십시오. 계속하기 위해 대략적인 이해가 필요하다면 계속 진행하는 것이 좋습니다.) 이 답변의 요점은 다음과 같습니다. "블록"을 완벽하게 정의하고 싶지만 아래의 논의는 내 조타실에서 훨씬 더 중요합니다.
@killermist가 쓴 것처럼 ZFS는 기본적으로 [ZFS] 블록 수준 중복 제거를 지원합니다.
ZFS에서는 기본적으로 활성화되어 있지 않습니다. 메모리가 충분하지 않은 상태에서 켜면 성능이 크게 저하됩니다. 또한 일화적으로 ZFS는 전체 해시 테이블을 RAM에 맞추려면 "1tb 저장소당 1gb RAM" 권장 경험 법칙보다 상당한 양이 필요합니다. 그러나 그럼에도 불구하고 하드웨어에 따라 여전히 40MB/s 이상의 쓰기 속도를 얻을 수 있습니다. 나는 ~2015년 드라이브를 실행하는 2008년 기술에서 그것을 얻습니다. 대부분의 보관 데이터에 대해서는 완벽하게 수용 가능합니다. ZFS 중복 제거의 가장 큰 단점은 중복 제거를 활성화하고 모든 것을 동일한 파일 시스템의 새 임시 디렉터리를 삭제하고 원본을 삭제한 다음 (현재 중복 제거된) 임시 콘텐츠를 다시 이동합니다. (오래된 파일을 삭제하는 것은 초기 복사/중복 제거 작업보다 시간이 더 오래 걸릴 수 있다는 점을 제외하면) 일반적으로 제가 하는 일은 기본적인 레이아웃을 변경하기 위해 어쨌든 정기적으로 어레이를 다시 설계해야 할 때까지 기다린 다음 이전 어레이에서 새로운, 중복 제거 기능이 켜져 있습니다.
Btrfs 중복 제거는 현재 작업을 수행하는 데 사용할 수 있는 타사 유틸리티만 사용하여 약간 더 개략적일 수 있습니다. (그러나 잘 지원되는 커널 API 및/또는 잘 지원되는 cp 옵션을 사용하며 어느 쪽이든 중복을 결정하기 위해 자체 논리가 필요하므로 정확하지 않기를 바랍니다.) 하지만 한 가지 잠재적인 이점은 이러한 유틸리티입니다. "대역 외"입니다. 그러나 대부분의 유틸리티에 대한 비용은 망치질을 하면서 성능을 저하시킨다는 것입니다. 이를 완료하는 데 몇 시간, 며칠, 심지어 몇 주가 걸릴 수 있습니다. (개인적으로 나는 1년에 한 번씩 HDD를 며칠 동안 망치는 것보다 대역 내 ZFS 중복 제거의 쓰기 성능이 항상 느린 편을 선호합니다.)
파일이 아닌 "블록"(그러나 또 다른 정의에서는)을 다루는 두 가지 Btrfs 솔루션은 다음과 같습니다.꿀벌, 그리고뚜퍼.
예를 들어, Bees는 사용 가능한 메모리 및 기타 요인을 기반으로 처음 실행 시 자체적으로 "블록" 크기를 임의로 정의합니다. (목적이나 특징, 메커니즘, 장단점을 잘못 표현한 것일지도 모르지만, 사용하지 않기 때문에 최근에는 옵션으로만 평가했습니다.)
Bees는 지속적으로 실행되고 디스크를 너무 세게 망치지 않도록 설계되었기 때문에 약간 하이브리드적일 수 있습니다. 하지만 여전히 기술적으로 ZFS 중복 제거와 같은 "대역 내"는 아닙니다. 단순히 사후에 중복 항목을 선택하고 가볍게 터치하여 중복 제거를 시도합니다. 임의로 정의된 블록 크기로 작업한다는 것은 설계상 RAM의 해시 테이블에 맞다는 것을 의미합니다. 단점은 (아마도) 동일한 "블록"의 범위가 있을 수 있지만 꿀벌이 속한 "블록"이 다르기 때문에 중복 제거를 수행할 수 없다는 것입니다.
"파일" 수준 Btrfs 중복 제거를 특별히 수행하는 유틸리티(예:베드업,듀퍼제거,rmlint및 기타)이 여전히 요구 사항을 충족할 수 있습니다. 확신할 수는 없지만 그럴 것 같습니다. 그 이유는 "cp --reflink=always" 명령도 실제로 "파일"을 중복 제거하지 않기 때문입니다. Btrfs를 중복 제거하는 중입니다.범위. 다시 링크된 "파일"이 변경되면 Btrfs는 변경된 범위를 고유한 범위까지만 중복 제거합니다. 파일의 나머지 부분은 중복 제거된 상태로 유지됩니다. 이는 중복 제거된 대용량 파일이 고유한 파일인 것처럼 분산될 수 있지만 여전히 대부분 중복 제거된 상태입니다.
(이것이 "파일"이 다시 링크되었는지 여부를 결정하는 것이 그토록 어려운 이유이기도 합니다. 그 개념이 실제로는 말이 되지 않기 때문입니다. 파일의 모든범위그 자체가 다른 동일 범위로 다시 연결될 수도 있습니다. 이는 의미가 있는 개념이지만, 공교롭게도 이는 대답하기 특히 어려운 질문입니다. 그렇기 때문에 Btrfs 중복 제거 유틸리티가 이미 중복 제거된 항목을 추적하지 않는 한 파일이 이미 중복 제거되었는지 "감지"하려고 노력할 가치가 없습니다. 검사할 refcount와 같은 속성은 없습니다. 어쨌든 다시 중복을 제거하는 것이 더 쉽습니다. 대조적으로, 전체 파일이 기존 방식으로 하드링크되었는지 여부를 결정하는 것은 쉽지 않습니다. 주어진 inode에 대한 st_nlink 수를 확인하십시오.)
"전체 파일 복제"가 없다는 것은 실제로 "무료" 스냅샷 및/또는 중복 제거를 지원하는 모든 CoW 파일 시스템의 본질적인 기능이며 Btrfs 범위, ZFS 블록 또는 다른 것을 처리하는 경우에도 마찬가지입니다. 그렇기 때문에 둘 중 하나가 귀하의 질문에 대한 답변이 될 수 있습니다. (내가 알고 있는 모든 작업을 수행할 수 있거나 수행할 계획인 다른 CoW 파일 시스템은 nilfs2, bcachefs 및 xfs 세 개 이상입니다.)
이에 대해 언급하지는 않았지만 제가 아는 한 중복 제거 기술은 파일 형식을 인식하지 않습니다. 즉, 어떤 중복 제거 장치도 *.jpg 메타데이터를 건너뛰고 중복 제거를 위해 압축된 이미지 데이터만 고려하는 방법을 알지 못합니다. 마찬가지로, 그들 중 누구도 파일 매직 넘버를 고려하지 않습니다(적어도 중복 제거를 위해 고려해야 할 사항을 결정하기 위해서는). 지속적이고 지속적인 정의 업데이트가 필요하기는 하지만 이는 킬러 기능이 될 수 있습니다. 파일을 범위, 블록 등의 추상적인 M:M 컬렉션으로 처리하는 동시에 디자인하기가 정말 어려울 수 있습니다.