BTRFS 파일 시스템에서 가상 디스크 이미지를 호스팅해야하는 이유


14

나는 BTRFS와 ZFS에 대해 잠시 동안 읽고 있었고 중요한 파일을 호스팅 할 때 CoW의 이점을 높이 평가하면서 현재 다음과 같은 딜레마에 당황하고 있습니다.

ZFS와 BTRFS 모두 무작위 쓰기 (예 : QCOW2, VDI 등)의 대상이되는 대용량 파일을 호스팅 할 때 성능이 저하되는 것처럼 보이면 누군가 VM을 호스트하기 위해 선택한 FS로 BTRFS를 사용하는 이유는 무엇입니까?

BTRFS의 경우 chattr 또는 nodatacow 마운트 옵션을 사용하여 CoW를 선택적으로 끌 수 있으므로 조각화 및 CoW로 인한 성능 저하를 줄일 수 있습니다.

그러나 Redhat 에 따르면 이는 "데이터 및 메타 데이터의 체크섬 확인을 비활성화하여 데이터 무결성이 떨어집니다." (압축 손실과 자연스럽게 원하는 CoW 외에도).

내가 묻는 질문에 따르면 : 누군가 누군가가 BTRFS를 선택한 이유는 다음과 같습니다.


있습니다 감소 된 데이터 무결성을 ext4에 또는 전부에 체크섬을 저장하기 때문에 손상을 감지 할 수없는없는 XFS와 같은 대부분의 다른 파일 시스템을 사용하는 것과 같은 것입니다.
basic6

1
@ basic6 알고 있습니다. 따라서 질문입니다.
앙드레 드 미란다

답변:


13

주요 사용 사례가 VM 이미지 또는 데이터베이스를 저장하는 경우 btrfs의 데이터 무결성 이점을 얻기 위해 잠재적 인 성능 문제를 수용하지 않으려는 경우 btrfs를 선택하려는 이유를 생각할 수 없습니다 xfs 또는 ext4 이상.

VMtr 이미지 디렉토리 (chattr + C 사용)에 대해서만 COW (Copy-On-Write)를 비활성화하는 것은 VM 이미지를 저장하는 것이 파일 시스템에 많은 용도 중 하나 일 때 주로 관련이 있습니다. 그런 다음 해당 단일 디렉토리에 대해 COW (Copy-On-Write)를 비활성화하는 것이 편리하지만 나머지 파일 시스템에 대한 btrfs의 모든 장점은 여전히 ​​유지됩니다.


파티션 테이블이없는 디스크가 있기 때문입니다. BTRFS를 사용하면 grub / etc를 XFS / EXT4 / etc에 직접 포함시킬 수 있습니다. VM을 저장하는 데 사용하는 BTRFS 위에 BTRFS의 CoW로 허용하는 파일 시스템을 찾고있었습니다. 이미지는 이상적이지 않으며 (호스트에서 스냅 샷과 btrfs-RAID10을 사용하고 있습니다) chattr + C는 파티션 테이블을 사용하는 것 이외의 유일한 옵션 인 것 같습니다. 그냥 파티션 테이블을 사용할 것 같아요.
Alex

5

BTRFS는 일부 쓰기 패턴에서 다른 파일 시스템보다 성능이 우수한 다른 디스크 형식을 가지고 있습니다. 특히 메타 데이터가 디스크에 기록되는 방식을 개선하는 데 많은 노력이 기울여졌으며 데이터 체크섬, 압축 및 스냅 샷과 같은 일부 고급 기능을 지원합니다. 큰 파일의 경우 메타 데이터 성능을 향상시키는 것은 일반적으로 중요하지 않습니다.

ZTR에 비해 BTRFS는 더 간단한 솔루션이며 Linux에서 더 잘 지원됩니다. 주요 단점은 디스크를 추가 할 때 확장되지 않으며 동일한 기능 세트가 없다는 것입니다.

XFS에 비해 성능이 낮은 솔루션입니다. 즉, 데이터 청크를 디스크에 쓰는 데 더 많은 프로세서 시간이 소요되며 최대 처리량으로 제한됩니다. 이는 체크섬 확인 비활성화와 같은 작업을 수행하여 어느 정도 완화 할 수 있지만 메타 데이터 정보가 개선 된 XFS에 비해 BTRFS의 주요 이점을 잃게됩니다. 즉, 체크섬 및 다른 저널링 (일부 상황에서는 더 나을 수 있음).

COW (Copy On Write) 지원 측면에서 XFS는 엄격한 COW보다 성능을 선호합니다. 즉, XFS는 확장 성 측면에서 메타 데이터 및 저널링 기능이 매우 뛰어나며 일반적으로 응용 프로그램에서 해당 데이터를 덮어 쓰도록 요청하는 경우 기존 디스크 블록을 덮어 쓰는 경우를 제외하고는 쓰기시 파일 데이터를 덮어 쓰지 않습니다. . 디스크 할당은 초기에 연속적 일 수 있고 VM의 수명 동안 연속적으로 유지되므로 VM의 경우에 좋습니다.


5

심지어 함께, BTRFS를 사용 nodatacow하고 모두 당신은 여전히 만들 수 있습니다 수동으로 데이터의 스냅 샷을 함께 CoW그것을 빨리하고 많은 메모리를 소모하지 않도록, 행동. 또한 이러한 스냅 샷은 LVM을 사용하는 것보다 융통성이 있습니다. 파일 시스템 아래에 파일 시스템이 인식하지 못하고 전혀 필요하지 않은 경우 사용할 수없는 파일 시스템 아래에 공간을 예약 할 필요가 없기 때문입니다. ZFS와 마찬가지로 네트워크를 통해 스냅 샷을 보내고받을 수 있으므로 백업 전략을 개선하는 데 도움이 될 수 있습니다. 따라서 nodatacowBTRFS 에서도 LVM을 사용하는 것보다 우수합니다.


3

클라우드 컴퓨팅 플랫폼으로 작업 한 후 실제 VM의 중요성이 덜한 데이터 및 기능의 컨테이너로 가상 머신에 대한 관점을 채택했습니다.

차라리 백업 복원 및 설치 배포 프로세스를 제대로 수행하고 VM의 무결성과 성능에 대해 걱정하지 않아도됩니다.

즉, BTRFS가 아닌 MD-raid보다 LVM을 통해 JFS / XFS / EXT4로 이동합니다. 더 이상 VM에 백업되지 않은 것을 절대 저장하지 마십시오. 문제가 발생할 경우 합리적인 시간 내에 VM을 새로 설치하기위한 스크립트와 절차를 마련하십시오.

그러나 이것은 다른 것보다 더 많은 개발 / 실험 시나리오입니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.