기존 벤치마크가 놓치는 워크로드에서의 Btrfs/ZFS/bcachefs
요약
본 글은 기존 벤치마크의 한계를 극복하고 Btrfs, ZFS, bcachefs 등 다양한 파일시스템을 실제 하드웨어 환경에서 심층적으로 테스트하는 과정을 공유합니다. GitHub 러너 기반의 간섭 문제를 최소화하기 위해 보정 절차를 거쳤으며, 대규모 디스크 및 복잡한 캐시 구성에서의 성능 비교에 초점을 맞추고 있습니다.
핵심 포인트
- GitHub 러너 한계를 극복하고 실제 하드웨어에서 벤치마크 진행 중
- Btrfs, ZFS, bcachefs 등 주요 파일시스템의 심층 비교 테스트 계획 공유
- 대규모 디스크 및 복잡한 캐시 구성에서의 성능 검증에 집중할 예정
- 파일시스템 선택 시 안정성과 현대적 기능 구현이 중요함
이 벤치마크를 만든 사람임. GitHub 러너 기반 벤치마크는 다른 사용자의 부하 간섭 등으로 한계가 크다는 걸 알고 있음. 그래서 각 테스트 전에 보정 절차를 실행해 완전히 신뢰할 수 없는 VM을 제외함. 이것으로 간섭을 줄일 수는 있어도 없앨 수는 없지만, 현재 593회 실행이 기록돼 있어 평균은 꽤 의미가 있을 것으로 봄.
실제 하드웨어도 적극적으로 구하고 있음. 몇 달 전 Kent Overstreet에게 Hetzner 머신을 받아 고장 나기 전까지 3회 실행을 마쳤음. 결과는 https://bartosz.fenski.pl/modern-fs-benchmark/real-hw/에서 볼 수 있음.
지금은 디스크가 훨씬 많은 머신에서 새 벤치마크를 실행하는 초기 단계임. https://bartosz.fenski.pl/modern-fs-benchmark/sas-hdd/에서 두 번째 실행이 진행 중이며, 실제 하드웨어에서는 GitHub 러너보다 한 번 실행하는 데 훨씬 오래 걸림. 디스크가 많아 더 복잡한 계층형 캐시 구성도 시험할 계획임.
벤치마크의 모든 소스는 공개돼 있으며, 전부 정확하다고 주장하는 건 아님. 개선 제안과 추가 질문을 환영함.
Hetzner와 몇 차례 연락했는데, 그냥 불량 머신을 받은 것 같음.
몇 달째 같은 얘기를 하고 있지만, 언젠가는 48코어 머신에서 자동 빌드를 다른 곳으로 옮겨 자동 성능 테스트에도 쓸 수 있게 할 예정임. 새로 받은 머신에는 삭제 코딩(EC) 성능 테스트용 HDD가 있고, Hetzner의 대형 머신에는 최고급 기업용 SSD가 장착돼 있음.
방금 Rust for Linux 콘퍼런스를 마쳤고 아직 집에 돌아가지 못했지만, 서식을 다듬어야 하는 발표 자료를 올려둠. https://evilpiepirate.org/~kent/Kangrejos-2026-bcachefs.pdf.
추가로 시험할 구성이 있음. 먼저 기존 벤치마크 비교에서 우승했던 듀얼 Ext4와 외부 저널용 32GB PCIe x4 SSD 조합을 넣으면 좋겠음. TRIM과 SSD 제조사 소프트웨어의 캐시 플러시를 실행한 뒤의 단독 F2FS도 필요함. 더 느릴 것으로 예상하지만 동일 하드웨어에서 얼마나 느린지 확인할 만함. DRBD와 CephFS도 각각 100Gbps 네트워크의 48U 서버 랙 전체에서 시험하면 좋겠음. 호스트마다 데이터용 PCIe x4 드라이브 하나를 두고, OS는 기본 드라이브에 설치하는 구성임.
CI가 공유 임시 VM에서 파일시스템별로 루프 장치를 사용하며 절대 MB/s 대신 추세와 비율을 비교하라고 하는데, 베어메탈이 아니면 결과 자체를 비교할 수 없는 것 아닌가? 다른 사용자가 동시에 디스크를 쓰고 있다면 어떻게 되는지 궁금함.
타당한 우려지만, 파일시스템과 VM 구성을 자동으로 빠르게 생성·삭제하려고 전용 테스트 하이퍼바이저를 쓰는 경우도 가능함. 기본 systemd 데몬과 SSH 데몬 외에는 부하가 없고 KVM에서 테스트 VM 하나만 실행한다면 베어메탈에 상당히 가까운 결과가 나올 수 있음.
이렇게 다양한 테스트마다 직접 OS를 재설치하고 파티션과 파일시스템을 만드는 건 무척 번거롭고 오래 걸릴 것 같음. 작성자도 성능보다 데이터 무결성이 주목적이라고 밝히고 있음. https://github.com/fenio/modern-fs-benchmark.
bcachefs의 좋은 성능을 보니 Kent와 다른 커널 개발자들이 합의해 커널 트리에 남기지 못한 게 더 아쉬움. 내 스토리지 배열에 정말 쓰고 싶지만, 커널에 포함된 파일시스템 중 현대적인 기능을 갖춘 선택지는 여전히 btrfs뿐이라 거기에 묶여 있음.
NixOS를 쓰면 됨. 좋은 선택임.
두 파일시스템은 사실상 Linux 커널에서 배척받아 영구적인 이등 시민 취급이고, 나머지 하나는 Red Hat에서 빠졌으며 신뢰성 이력도 의심스러움. 대체 무엇을 골라야 할까?
나라면 다른 OS에서 ZFS를 쓰겠음.
Red Hat에는 고마울 게 없음. 서버는 Debian으로 옮겼고, 다행히 Fedora는 여전히 btrfs를 지원함.
ZFS는 배척받는 게 맞고 저작권 문제를 피하기도 어려움. 반면 bcachefs는 일시적으로 좌절을 겪은 것이며, 결국 해결되길 기대함.
당연히 xfs/lvm-raid10 또는 ext4/lvm-raid10을 고르면 됨.
스토리지가 비싸진 지금은 bcachefs가 최고의 Linux 파일시스템임. 크기와 종류가 다른 장치를 섞을 수 있고, 전경·배경용 장치를 나눠 성능을 조절하며 각 트랜잭션의 압축 설정도 다르게 지정할 수 있음.
파일이나 디렉터리별로 replicas=N 을 설정할 수도 있음. 다시 내려받거나 빌드할 수 있는 파일은 복제본을 줄이고, 중요한 파일은 더 많이 보관하는 식으로 활용 가능함.
푸시할 때마다, 또 2시간마다 희소 파일 기반 루프 장치 4개에 파일시스템을 구성해 테스트한다는 설명임. 실제 하드웨어에 비용이 든다는 건 이해함. 작성자는 적당한 서버가 월 70유로라고 했지만, 적어도 실제 SSD·HDD와 희소 파일 기반 루프 장치를 비교한 기준 측정은 있어야 결과에서 뭔가를 얻을 수 있을 것 같음.
안타깝게도 AI 대재앙 때문에 이런 일을 취미로 하기가 더 어려워짐.
AI 자동 생성 콘텐츠
본 콘텐츠는 GeekNews의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기