일부 파일/디렉토리의 깨끗한 복사본을 만들려고 노력하고 있지만 제가 알고 있는 여러 가지 방법 중 어느 것도 최적인 것 같지 않습니다.
예를 들어, btrfs를 사용하면 cp --reflink=auto파일의 oxen 복사본을 빠르게 생성할 수 있습니다.
내가 시도한 것:
- 심볼릭 링크: 불량. 파일 이름이 바뀌었고 링크가 끊어졌습니다.
- 하드 링크: 더 좋지만 여전히 나쁩니다. 한 파일을 변경하면 다른 파일도 변경되며 반드시 다른 파일이 변경되는 것을 원하지는 않습니다.
- 데이터 세트의 스냅샷을 생성한 다음 스냅샷을 복제합니다. 작동하지만 그다지 효과적이지는 않습니다. 일반적으로 저는 전체 데이터 세트의 복사본을 찾거나 해당 복사본을 다른 데이터 세트처럼 작동하도록 만들지 않습니다. 그런 다음 복제본/스냅샷/원본 사이의 상위/하위 관계가 있는데, 제가 아는 한 이를 깨는 것은 불가능하지는 않더라도 어렵습니다.
- 중복 제거를 사용
zfs send/receive하고 활성화하여 데이터세트를 새 데이터세트에 복사합니다. 이렇게 하면 복제된 상위/하위 관계를 사용하지 않아도 되지만 여전히 불필요하게 다른 데이터세트가 생성되고 파일을 100% 읽어야 하는 것과 관련된 속도 저하 문제가 여전히 발생합니다. 문제가 다시 언급됩니다. 블록을 쓰는 대신 블록을 사용하세요. - 파일을 복사하고 중복 제거가 해당 작업을 수행하도록 합니다. 이 방법은 작동하지만 파일을 100% 읽어야 하고 쓰기보다는 블록에서 다시 참조해야 하기 때문에 속도가 느립니다.
zfs 보내기/받기 및 물리적 복사 또는 rsync의 속도 저하는 대부분의 콘텐츠가 압축되어 저장되고 읽기 중에 압축을 푼 다음 중복 제거가 중복 블록을 참조하기 시작하기 전에 압축되어야 한다는 사실로 인해 더욱 복잡해집니다.
내 모든 연구에서 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는 디스크가 블록을 쓰는 것보다 훨씬 빠르게 블록을 읽을 수 있으므로 이는 문제가 되지 않습니다. (예, 그것보다 더 복잡하지만 이것이 요점입니다.)
질문의 사소한 부분에 대해 설명이 길어져서 죄송합니다만, 오해를 풀고 싶었습니다.