btrfs에 대해 배우기 시작하고 전환을 고려하고 있습니다.
btrfs에 대한 나의 현재 의견은 그것이 git과 매우 유사하게 작동하고 모든 것이 추적되며 변경 후 30초마다 커밋이 이루어진다는 것입니다. 그러나 내 직감은 내가 오해하고 있음에 틀림없다고 말합니다. 그렇지 않으면 하드 드라이브 공간이 더 빨리 소모될 것입니다. 따라서 모든 것을 추적하고 변경 영역 후 30초마다 스테이징에 파일을 추가하는 git과 더 유사한지 궁금합니다. 스냅샷에서만 커밋됩니다.
스냅샷을 찍지 않으면 단일 파일을 몇 가지 변경 사항 전으로 롤백할 수 있나요? 아니면 스냅샷을 찍을 때만 보관되나요? 즉, for 루프를 10,000번 실행하고 그 사이에 31초의 휴면 시간을 두고 파일에 추가하면 해당 파일에 대한 10,000개 항목의 조상 트리가 표시되고 각 항목으로 돌아갈 수 있습니까?
루트의 btrfs 스냅샷을 사용하고 VMware/VirtualBox 스냅샷처럼 생각할 수 있습니까? 분기를 닫고, 해당 상태를 저장하고, 다른 분기로 이동하고, 시작하고, 분기되는 스냅샷 분기를 갖도록 변경한 다음 트리를 따라 원하는 곳으로 이동할 수 있는 곳은 어디입니까? 그렇다면 스냅샷 트리 노드를 선택할 수 있는 부트로더가 있습니까? (각 스냅샷에 대해 grub.cfg 메뉴 항목을 생성할 필요가 없습니다.)
스냅샷 A에 태그를 지정하고 변경한 후 B로 태그를 지정합니다. 스냅샷 A로 돌아가서 변경하는 경우(부팅에서 /var/log를 변경하는 것만으로도) 해당 변경 사항은 "분리된" 또는 "태그 없는" 스냅샷에서 적용되므로 B로 돌아가면 해당 변경 사항은 적용되지 않습니다. 눈에 띄나요? 그렇다면 이 "표시되지 않은" 스냅샷을 변경하고 이를 표시하기 전에 실수로 다른 스냅샷에 대한 변경을 요청하면 어떻게 됩니까?
파일이 삭제되면 "이 파일이 삭제되었습니다" 메타데이터가 기록되어 파일의 모든 버전이 여전히 공간을 차지합니까? 아니면 아직 이를 가리키는 스냅샷이 없다고 가정하면 이전 버전이 모두 삭제되나요?
예를 들어 소스에서 gcc를 빌드하면 빌드 디렉터리가 5~8GB가 될 것 같아요. 정기적으로 소스에서 빌드하면 많은 하드 드라이브 공간을 "소모"하게 됩니다. 그렇죠? (삭제가 삭제되는 파일의 모든 내용을 제거한다고 가정하더라도 make clean 없이 빌드 프로세스 중에 얼마나 많은 파일이 삭제되는지 알 수 없습니다. 기존 개체 파일이 기술적으로 삭제되었거나 거기에 있습니까? "다시 작성".)
답변1
Btrfs에서 스냅샷은 특별한 것이 아니며 단지 Btrfs 하위 볼륨일 뿐이라는 점만 기억하면 대부분의 질문에 답할 수 있다고 생각합니다. 공교롭게도 생성 당시에는 비어 있는 것이 아니라 초기 콘텐츠가 있었고 해당 초기 콘텐츠에 대한 저장 공간은 스냅샷이 나온 하위 볼륨과 공유되었습니다.
스냅샷은 (전체) 복사본과 비슷하지만 공유 스토리지로 인해 더 경제적입니다.
- 스냅샷을 찍지 않으면 단일 파일을 몇 가지 변경 사항 전으로 롤백할 수 있나요?
습관. 일반 파일 시스템과 마찬가지로 파일 수정은 파괴적입니다. 마술처럼 이전 버전으로 돌아갈 수는 없습니다.
- 루트의 btrfs 스냅샷을 사용하고 VMware/VirtualBox 스냅샷처럼 생각할 수 있습니까?
VM 디스크 이미지는 일반적으로 파일 시스템이나 파일 시스템의 파일이 아닌 블록 장치이므로 약간 다르다고 가정합니다.
제 생각엔 Btrfs 파일을 VM 가상 블록 장치의 백업 저장소로 사용할 수 있을 것 같습니다. 이 경우 이 질문에 대한 대답은 '예'입니다. NOCOW 옵션을 사용하지 않는 한(실제로 디스크 이미지에 권장됨) 아마도 그렇지 않을 것입니다. 기록 중 복사가 스냅샷을 작동하게 만드는 마법이기 때문입니다.
- 스냅샷 A에 태그를 지정하고 변경한 후 B로 태그를 지정합니다. 스냅샷 A로 돌아가서 변경하는 경우(부팅에서 /var/log를 변경하는 것만으로도) 해당 변경 사항은 "분리된" 또는 "태그 없는" 스냅샷에서 적용되므로 B로 돌아가면 해당 변경 사항은 적용되지 않습니다. 눈에 띄나요?
Btrfs의 모든 하위 볼륨(스냅샷 포함)에는 이름이 있으므로 "태그가 지정되지 않은" 스냅샷을 가질 수 없습니다.
일반적으로 하나의 Btrfs 하위 볼륨에서 변경한 내용(스냅샷으로 생성되었는지 여부)은 다른 Btrfs 하위 볼륨에서 전혀 보이지 않습니다. 스냅샷은 복사본과 비슷하지만 더 경제적이라는 점을 기억하세요.
- 파일이 삭제되면 "이 파일이 삭제되었습니다" 메타데이터가 기록되어 파일의 모든 버전이 여전히 공간을 차지합니까?
파일이 삭제되면 해당 디렉토리 항목도 삭제됩니다. 이는 디렉토리에 대한 수정이며 모든 수정과 마찬가지로 수정이 발생한 하위 볼륨에만 적용됩니다. 그런 다음 파일 시스템의 다른 부분에서 저장 공간을 사용하지 않는 경우에만 파일이 해제됩니다.
여러 스냅샷 간에 공유되어 저장된 파일을 삭제하는 것은 일반 파일 시스템에서 여러 (하드) 링크가 있는 파일을 삭제하는 것과 매우 유사합니다. 저장소 [inode]가 더 이상 참조되지 않으면 해제됩니다.
- 예를 들어 소스에서 gcc를 빌드하면 빌드 디렉터리가 5~8GB가 될 것 같아요. 정기적으로 소스에서 빌드하면 많은 하드 드라이브 공간을 "소모"하게 됩니다. 그렇죠?
여러 다른 디렉토리에서 여러 번 빌드 하면 gcc
점점 더 많은 공간을 사용하게 됩니다. 빌드 간 복사본을 삭제하거나 매번 동일한 빌드 디렉터리를 덮어쓰는 경우에는 계속해서 더 많은 공간을 사용할 특별한 이유가 없습니다.
답변2
btrfs에 대한 나의 현재 견해는 그것이 git과 매우 유사하게 작동한다는 것입니다.
그러나 실제로는 그렇지 않습니다.
cp -a /path/to/source /path/to/snapshot
스냅샷은 데이터를 공유하고 스냅샷을 찍는 속도가 빠르다는 점을 제외하면 이와 유사하게 작동합니다 . 그러나 해당 데이터는 쓰기 시 복사됩니다. 파일에 쓰면 기록된 부분은 더 이상 공유되지 않습니다.
( btrfs에는 스냅샷과 매우 유사한 복사본을 만드는 옵션이 cp
있습니다 .)--reflink
(1) 일반적으로 그렇지 않습니다. 스냅샷을 찍는 경우에만 가능합니다.
(2) LVM 스냅샷에 더 가깝습니다. 그러나 btrfs send를 사용하여 이동할 수 있습니다. 하지만 또 다른 스냅샷을 만들 수는 있지만 브랜치 같은 것은 없습니다.
(3) 그들은 A의 일부가 될 것이다. B는 변함이 없습니다. A가 변경됩니다.
(4) 파일을 삭제하여 공간을 확보하세요. 버전은 스냅샷의 일부로만 유지됩니다.
(5) 스냅샷을 생성하기로 결정하지 않는 한 오류가 없으며 문제가 되지 않습니다. 물론 이는 공간을 차지합니다(스냅샷을 삭제하여 공간 확보).