▲

GN⁺: OpenZFS 중복 제거 기능 개선, 사용 자제 권고

 (despairlabs.com)
1P by neo 15일전 | favorite | 댓글 1개

OpenZFS의 중복 제거란 무엇인가?

  • 중복 제거의 정의: OpenZFS에서 데이터를 디스크에 쓰기 전에 해당 데이터가 이미 디스크에 존재하는지 확인하고, 존재한다면 새로운 쓰기를 하지 않고 기존 복사본에 대한 참조를 추가하는 것임.
  • 중복 제거의 도전 과제: 데이터가 이미 디스크에 있는지 확인하고, 그 위치를 아는 것이 어려움. 이는 추가적인 입출력(IO)을 필요로 하며, 이로 인해 성능 저하가 발생할 수 있음.

중복 제거는 어떻게 작동하는가?

  • 작동 방식: 중복 제거가 활성화되면, 데이터 블록이 준비되고 체크섬이 계산됨. 기존에는 메타슬랩 할당자가 공간을 할당했지만, 중복 제거가 활성화되면 체크섬을 중복 제거 테이블에서 조회함.
  • 중복 제거 테이블: 체크섬을 키로 사용하고, 디스크 위치와 참조 수를 값으로 사용하는 해시 테이블 형태로 저장됨. 이는 풀 메타데이터의 일부로 간주됨.

전통적인 중복 제거의 문제점

  • 중복 제거 테이블의 문제: 전통적인 중복 제거는 OpenZFS의 디스크 해시 테이블 객체를 사용하여 구현됨. 이는 복잡한 구조로, 중복 제거와 같은 응용에는 적합하지 않음.
  • 메모리 사용량: 중복 제거 테이블을 읽는 것은 ARC에 캐시되며, 충분한 RAM이 있으면 테이블 업데이트의 읽기 부분을 줄일 수 있음.
  • 고유 항목 문제: 중복 제거 테이블에서 고유 항목을 추적하는 데 드는 공간이 문제임. 참조 수가 1인 블록은 중복 제거 테이블에서 공간을 차지하며, 동일한 데이터가 쓰이지 않으면 비용을 회수할 수 없음.

빠른 중복 제거는 어떻게 문제를 해결하는가?

  • 라이브 항목 목록 축소: 메모리 사용량을 줄이기 위해 라이브 항목 목록의 메모리 발자국을 줄임. 새로운 중복 제거 테이블은 항목의 "값" 부분이 72바이트로 줄어듦.
  • 중복 제거 로그: 라이브 항목 목록을 대신하여 로그를 사용하여 변경 사항을 기록하고, 충돌 복구 시 로그를 재생함. 로그는 메모리에 저장되어 빠른 조회를 가능하게 함.
  • 증분 로그 플러싱: 로그의 크기를 관리하기 위해 일부 로그를 매 트랜잭션마다 ZAP에 기록함. 메모리 압박이 있을 때 로그 플러싱을 가속화함.

GN⁺의 정리

  • OpenZFS의 새로운 "FastDedup" 기능은 전통적인 중복 제거의 문제점을 해결하기 위해 개발되었음. 메모리 사용량을 줄이고, 로그를 통해 효율적인 데이터 관리를 가능하게 함.
  • 중복 제거는 특정 워크로드에서만 유용하며, 일반적인 용도로는 여전히 비효율적일 수 있음. 이는 중복 제거 테이블의 관리 오버헤드가 크기 때문임.
  • 비슷한 기능을 가진 다른 프로젝트로는 Btrfs의 중복 제거 기능이 있으며, 이는 다른 파일 시스템에서의 대안이 될 수 있음.
▲
neo 15일전  [-]
Hacker News 의견

  • 제목에 끌려 클릭했지만 ZFS에 관심이 없었음에도 거의 모든 글을 읽게 되었음. 글이 명확하게 설명되어 있었고, 모바일 CSS 테마가 특히 마음에 들었음. 간결한 요약은 글의 하단에 있음.

  • copy_file_range 논의 외에도, 파일 시스템에서 동일한 해시를 가진 1MB 이상의 파일을 찾아 선택적으로 중복 제거를 적용할 수 있으면 좋겠음.

  • 전통적인 중복 제거의 문제는 오버헤드가 너무 커서 특정 작업 부하를 제외하고는 효과를 보기 어려움. Pure와 Dell/EMC 배열에서 VMWare 작업 부하에 대해 3:1 중복 제거/압축 절감 효과를 보았음.

  • 중복 제거의 효과는 해시되는 블록의 크기에 크게 영향을 받음. 블록이 작을수록 일치하는 블록이 있을 확률이 높아짐. 개인적으로 4KB 블록 크기를 선호함.

  • "오프라인" 중복 제거나 "게으른" 중복 제거를 원함. 중복 제거가 활성화되면 모든 쓰기와 해제 작업이 중복 제거 테이블에 대한 조회와 쓰기를 요구함. 데이터 쓰기 시 빠르게 완료되기를 원함.

  • 빠른 중복 제거에 대해 매우 기대하고 있음. ArchiveBox 데이터에 ZFS 중복 제거를 사용하고 싶었음. 많은 URL을 아카이브하고 파일 시스템이 모든 것을 압축하도록 하는 것이 가능해질 것 같음.

  • 개인 아카이브에 ZFS 중복 제거를 사용해 왔으며, 현재 디스크 공간을 3배 줄이고 있음. ZFS는 신뢰성 면에서 매우 잘 작동했으며, 데이터 손실을 방지할 수 있었음.

  • 일반적인 중복 제거는 이론적으로는 좋지만 실제로는 잘 작동하지 않음. IPFS는 가변 크기의 조각을 사용하여 데이터를 중복 제거하려고 하지만 실제로는 차이가 없고 복잡성만 증가시킴.

  • 디스크 컨트롤러의 전용 하드웨어가 ECC 같은 계산을 위해 블록의 해시를 시스템에 노출할 수 있도록 개선되면 좋겠음.

  • 파일 시스템의 API가 완전히 다른 형태였으면 좋겠음. 모든 OS의 파일 시스템 API는 호환성 때문에 고착되어 있음.

  • 쓰기 성능이 중요하다면, 쓰기 시 중복 제거를 할 필요가 없음. 중복 제거는 나중에, 동시에, 그리고 낮은 우선순위로 수행하면 됨.

답변달기