Snapper 또는 Snapper와 같은 것을 사용 하여 시간 기반 스냅 샷을 만들 수 있도록 데이터 드라이브에서 btrfs를 사용하는 것을 고려 하고 있습니다. 이전 버전의 데이터를 찾아 볼 수 있다고 생각합니다. 드라이브 고장으로 인해 데이터와 스냅 샷이 지워지기 때문에 현재 오프 사이트 백업에 추가됩니다.
내 이해에 따르면 btrfs 스냅 샷은 많은 공간 (메타 데이터 및 변경된 블록과 오버 헤드)을 차지하지 않으므로 공간이 제약되는 것처럼 보이지 않습니다.
데이터, 변경된 데이터 및 메타 데이터를위한 충분한 디스크 공간이 있다고 가정 할 때 백만 개의 스냅 샷이있는 경우 (예 : 2 년 동안 매분마다 스냅 샷) 혼란을 유발할 수 있습니까?
스냅 샷 수에 실질적인 제한이있는 경우 파일 수 및 / 또는 파일 크기에 따라 달라 집니까?
답변:
거의 몇 년 동안 btrfs파일 시스템을 사용하는 사람으로서 이제는 쉽게 도달 할 수있는 스냅 샷 수에 실질적인 제한이없는 것 같습니다. 그러나 몇 가지주의 사항이 있습니다. 파일 시스템은 조각화로 이어질 수 있습니다. 따라서에 내장 된 온라인 조각 모음 기능을 사용하는 것이 좋습니다 . 또한 압축 기능 을 잘 활용할 수 있습니다 . 이러한 조치는 합리적 수준의 컴퓨터에서 많은 스냅 샷을 생성하지 못했을 때 발생할 수있는 대부분의 성능 문제를 처리해야합니다.Arch Linux2btrfsbtrfsbtrfs
아시다시피 btrfs하위 볼륨을 파일 시스템으로 취급하므로 스냅 샷 수는 파일 크기에 따라 제한됩니다. btrfs위키 에 따르면 도달 할 수있는 최대 파일 크기는 2^64 byte == 16 EiB[1] 입니다.
이러한 제한 외에도 btrfs파일 시스템 에서 여유 공간을 확인하는 것이 까다로울 수 있기 때문에 즉각 인식하지 않고 공간이 부족한 경우 항상 문제가 발생할 수 btrfs있습니다. 실제로 남은 공간을 쉽게 추적 할 수 있습니다. 이 시나리오를 막을 수있는 한 가지 방법은 할당량을 사용하는 것입니다. 이를 통해 사용자 (또는 하나 인 경우 사용자)는 일정량의 공간 만 사용할 수 있습니다. 이 개념은 여기 와 여기 에서 매우 잘 논의 됩니다 .
마지막으로 경고는 아닙니다 : 저는 btrfs파일 시스템 전문가가 아니며 한참 전에 같은 질문을 받았을 때만 이것에 대해 읽습니다. 또한 항상 btrfs"빠르게 움직이는 대상"( Arch Linux위키 페이지 에서 도난당한 좋은 표현 )이라는 문제가 있기 때문에 상황이 바뀔 수 있습니다.
기술적으로 스냅 샷 수에는 제한이 없지만 BTRFS 메일 링리스트 에 요청했습니다 .
(실제) 답변은 btrfs 사용 방법에 따라 어느 정도 다릅니다.
Btrfs에는 너무 많은 스냅 샷 (또는 실제로는 reflink 스냅 샷에서 사용하는 reflink를 사용한 중복 제거가 동일한 스케일링 문제를 유발할 수 있음)으로 인해 스케일링 문제가 있으며 스냅 샷 된 하위 볼륨 당 단일 또는 낮은 두 자리 수의 스냅 샷이 그 이유에 대한 강력한 권장 사항으로 남아 있습니다.
그러나 스케일링 문제는 주로 btrfs 유지 보수 명령 자체, 밸런스, 점검, 하위 볼륨 삭제에 영향을줍니다. 수백만 개의 스냅 샷이 예를 들어 효과적으로 작동 할 수없는 균형을 유지하지만 (일종의 작업이지만 몇 달이 걸릴 수 있음) 파일 읽기 및 저장과 같은 일반적인 파일 시스템 작업은 조각화가 문제가되는 범위를 제외하고는 영향을받지 않는 경향이 있습니다 ( 조각 모음과 같은 단계를 수행하지 않으면 btrfs와 같은 소 파일 시스템이 조각화로 표시됩니다.
스냅 샷을 타임머신 / 스냅 퍼와 유사한 아카이브 백업으로 사용하는 것은 좋은 생각이 아닙니다.
총 2 개의 64 개의 스냅 샷과 하위 볼륨을 만들 수 있습니다.
btrfs디자인 위키 페이지 (empahsis 광산) 말한다 :
서브 볼륨은 기본적으로 파일과 디렉토리를 보유하는 명명 된 btree입니다. 그들은 나무 뿌리의 나무 안에 inode를 가지고 있으며 루트가 아닌 소유자와 그룹을 가질 수 있습니다. 하위 볼륨에는 블록 할당량을 부여 할 수 있으며이 할당량에 도달하면 새로운 쓰기가 허용되지 않습니다. 하위 볼륨 내부의 모든 블록과 파일 범위는 참조 횟수로 계산되어 스냅 샷이 가능합니다. FS에 최대 2 개의 64 개의 하위 볼륨을 만들 수 있습니다.
스냅 샷은 하위 볼륨과 동일 하지만 루트 블록은 처음에 다른 하위 볼륨과 공유됩니다. 스냅 샷이 작성되면 루트 블록의 참조 수가 증가하고 COW (Copy On Write) 트랜잭션 시스템은 스냅 샷 또는 소스 서브 볼륨에서 작성된 변경 사항이 해당 루트에 대해 개인용임을 확인합니다. 스냅 샷은 쓰기 가능하며 여러 번 다시 스냅 샷 할 수 있습니다. 읽기 전용 스냅 샷이 필요한 경우 블록 할당량은 생성시 1로 설정됩니다.