나는 일부 파일/디렉토리의 복사본을 만들려고 노력하고 있지만 내가 아는 여러 가지 방법 중 모두 차선책인 것 같습니다.
예를 들어, btrfs는 cp --reflink=auto파일의 소 복사본을 빠르게 생성할 수 있습니다.
내가 시도한 것:
- Symlinks: 좋지 않습니다. 파일 이름이 바뀌었고 링크가 끊어졌습니다.
- 하드링크: 더 좋아졌지만 여전히 좋지는 않습니다. 한 파일을 변경하면 다른 파일도 변경되므로 반드시 다른 파일이 변경되는 것을 원하지는 않습니다.
- 데이터 세트의 스냅샷을 생성한 다음 스냅샷을 복제합니다. 이 방법은 작동할 수 있지만 잘 작동하지는 않습니다. 전체 데이터 세트의 복사본을 찾고 있지 않거나 복사본이 다른 데이터 세트처럼 작동하는 것을 원하지 않는 경우가 많습니다. 그런 다음 복제본/스냅샷/원본 사이에 상위/하위 관계가 있는데, 제가 이해하기로는 이를 깨는 것이 불가능하지는 않더라도 어렵습니다.
- 을 사용
zfs send/receive하고 중복 제거를 활성화하여 데이터세트를 새 데이터세트에 복제합니다. 이렇게 하면 클론을 사용하는 상위/하위 관계가 방지되지만 여전히 불필요하게 다른 데이터세트가 생성되고 파일을 100% 읽어야 하는 것과 관련된 속도 저하 문제가 여전히 발생합니다. 블록이 기록되는 대신 다시 참조됩니다. - 파일 복사 및 중복 제거 작업 수행: 이 방법은 작동하지만 파일을 100% 읽어야 하고 블록을 쓰는 대신 다시 참조해야 하기 때문에 속도가 느립니다.
대부분의 항목이 압축되어 저장되고 읽기 중에 압축을 푼 다음 중복 블록을 참조하기 위해 중복 제거가 시작되기 전에 압축해야 하기 때문에 zfs 보내기/받기 및 물리적 복사 또는 재동기화 속도가 더욱 악화됩니다.
내 모든 연구에서 btrfs의 --reflink의 단순성과 조금이라도 유사한 것을 찾을 수 없었습니다.
그렇다면 ZFS에서 소 복사본을 만드는 방법이 있습니까? 아니면 "물리적으로" 복사하고 중복 제거를 수행하는 것이 유일한 실제 옵션입니까?
답변1
위에서 설명한 옵션 3이 아마도 최선의 방법이라고 생각합니다. 원하는 것의 가장 큰 문제는 ZFS가 실제로 데이터세트/스냅샷 수준에서만 이 쓰기 시 복사를 처리한다는 것입니다.
정확한 환경에서 제대로 작동하는지 확인하지 않는 한 중복 제거 사용을 피하는 것이 좋습니다. 저는 한 명의 사용자나 VM 저장소를 추가로 이동할 때까지 중복 제거가 훌륭하게 작동하다가 성능 절벽에서 떨어져 많은 문제를 일으킨 경험이 있습니다. 처음 10명의 사용자에게 잘 작동하는 것처럼 보이기 때문에 11번째(또는 12번째, 13번째 등)를 추가하면 컴퓨터가 넘어질 수 있습니다. 이 방법을 사용하려면 프로덕션 환경을 정확하게 모방하는 테스트 환경이 있고 해당 환경에서 잘 작동하는지 절대적으로 확인하십시오.
옵션 3으로 돌아가서 이러한 방식으로 관리하려는 각 파일 시스템 트리를 보유할 특정 데이터 세트를 설정해야 합니다. 설정하고 처음으로 채운 후에는 스냅샷을 찍고(약간 다를 수 있는 데이터 세트당 하나) 복제본으로 승격하세요. 다시는 원본 데이터세트를 건드리지 마세요.
예, 이 솔루션에는 문제가 있습니다. 그렇지 않다고 말하는 것은 아니지만 ZFS의 제한을 고려하면 여전히 가장 좋은 것일 수 있습니다. 클론을 효과적으로 사용하는 사람에 대한 언급을 찾았습니다.http://thegreyblog.blogspot.com/2009/05/sparing-disk-space-with-zfs-clones.html
저는 btrfs에 대해 잘 알지 못하지만 원하는 옵션을 지원한다면 해당 서버에서 Linux 및 btrfs를 사용하여 이러한 데이터 세트를 지원하기 위해 별도의 서버를 설정하는 것을 고려해 보셨나요?
답변2
옵션 5가 가장 좋습니다.
옵션 3의 상위/하위 데이터 세트와 관련하여 복제본을 승격할 수 있으며 더 이상 복제된 데이터 세트의 하위가 아닙니다. 여전히 추가 블록을 사용하지 않습니다. 편집하다:이는 부모/자식 관계를 역전시킬 뿐, 파괴하지는 않는다는 점에 유의하세요.
압축/암호화되어 복사 속도가 느려진다는 점은 완전히 거짓입니다. 프로세서는 블록 장치보다 훨씬 빠릅니다(SSD를 사용하는 경우에도). 몇 가지 예를 들어, 블록을 읽는 데 10초가 걸리지만 압축을 푸는 데는 1초, 해독하는 데는 2초밖에 걸리지 않는다고 가정해 보겠습니다. 블록 1은 10초 안에 읽고 CPU로 전송됩니다. 디스크가 블록 2를 읽기 시작하는 동안 CPU는 압축 해제 및 암호 해독을 시작합니다. CPU는 3초 안에 작업을 완료한 후 다음 7초 동안 디스크를 기다리게 됩니다. 한편 디스크는 블록 압축 여부에 관계없이 두 블록을 읽는 데 정확히 동일한 시간(20초)을 소비했습니다.
마찬가지로 쓰는 동안 첫 번째 블록만 지연됩니다. CPU는 블록 1을 압축/암호화하여 디스크로 보냅니다. 디스크가 블록 1을 쓰는 동안 CPU는 후속 블록을 압축/암호화하기 시작합니다. CPU는 디스크가 블록을 쓸 수 있는 것보다 훨씬 빠르게 블록을 처리하므로 문제가 되지 않습니다. (예, 이것보다 더 복잡하지만 이것이 요점입니다.)
질문의 사소한 점에 대해 지나치게 길게 설명해서 죄송합니다. 하지만 그 오해를 바로잡고 싶었습니다.