Btrfs ve ZFS Karşılaştırması

Yeni bir sunucu kurarken "ext4 mü, XFS mi" sorusunu geçtiyseniz sıradaki soru neredeyse her zaman aynı oluyor: Btrfs ve ZFS karşılaştırması yapıp hangisini seçeceğim? İkisi de copy-on-write mimarisine sahip, ikisi de sağlama toplamıyla veri bütünlüğünü koruyor, ikisi de snapshot alıyor ve sıkıştırma yapıyor. Kâğıt üzerinde özellik listeleri o kadar benziyor ki karar vermek zorlaşıyor. Oysa aradaki farklar özellik listesinde değil, o özelliklerin hangi durumlarda güvenilir çalıştığında saklı.

Bu yazıda iki dosya sistemini pazarlama dilinden uzak biçimde karşılaştıracağım: mimari yaklaşımları nerede ayrışıyor, RAID desteklerinde hangi ciddi uyarı var, snapshot davranışları neden farklı hissettiriyor, kaynak kullanımı ve kurulum kolaylığı nasıl değişiyor. Sonunda da "şu durumdaysan şunu seç" biçiminde net bir karar tablosu bırakacağım, çünkü doğru cevap iş yükünüze ve donanımınıza bağlı.

İki Dosya Sistemi de Aynı Sorunu Çözüyor#

Btrfs ve ZFS aynı tarihsel problemden doğdu: klasik yığında dosya sistemi, birim yöneticisi ve RAID katmanı birbirinden habersiz çalışıyordu. Bir blok bozulduğunda RAID katmanı iki kopyanın farklı olduğunu görebilir ama hangisinin doğru olduğunu bilemezdi. Her ikisi de bu katmanları birleştirerek çözdü: hem birim yönetimini hem dosya sistemini tek yazılıma aldılar, her bloğun sağlama toplamını tuttular ve bozuk bloğu yedeğinden onarabilir hale geldiler.

Copy-on-write yaklaşımı da ortak. Hiçbiri var olan bloğun üzerine yazmaz; değişiklik yeni bir bloğa yazılır ve işaretçi atomik olarak güncellenir. Bunun iki güzel yan etkisi vardır: elektrik kesintisinde dosya sistemi yarım kalmaz ve snapshot almak neredeyse bedava olur, çünkü snapshot sadece o anki blok işaretçilerini dondurmaktan ibarettir. ZFS tarafındaki kavramları hiç görmediyseniz, devam etmeden önce ZFS nedir ve avantajları yazısındaki pool, vdev ve dataset açıklamaları bu karşılaştırmayı çok daha anlaşılır kılar.

Mimari Fark: Havuz Yönetimi ve Esneklik#

ZFS katı ve öngörülebilir bir hiyerarşi dayatır. Diskler vdev'leri, vdev'ler pool'u, pool da dataset'leri oluşturur. Bu yapı dayanıklılığı netleştirir ama esnekliği kısar: bir vdev oluşturulduktan sonra içindeki disk sayısını değiştirmek çoğu yapılandırmada mümkün değildir ve havuzu küçültmek pratikte yapılmaz. Büyütmenin yolu genellikle yeni bir vdev eklemek ya da diskleri teker teker daha büyükleriyle değiştirmektir.

Btrfs ise tam tersi bir felsefeyle tasarlandı: her şey çalışırken değiştirilebilsin. Havuza farklı boyutlarda disk ekleyebilir, çıkarabilir, dosya sistemini küçültebilir ve RAID profilini sistem çalışırken dönüştürebilirsiniz. Bu, elinizdeki karışık diskleri değerlendirmek istediğiniz durumlarda gerçek bir avantajdır:

# Btrfs havuzuna çalışırken yeni disk ekle
btrfs device add /dev/sdd /mnt/veri

# Veriyi yeni diske de yaymak için yeniden dengele
btrfs balance start -dconvert=raid1 -mconvert=raid1 /mnt/veri

# Bir diski havuzdan çıkar (veri diğerlerine taşınır)
btrfs device remove /dev/sdb /mnt/veri

ZFS'te bunun karşılığı çok daha sınırlıdır; zpool add ile vdev eklersiniz ama eklediğiniz vdev'i genelde geri çıkaramazsınız. Yani ZFS ilk kurulumda doğru karar vermenizi bekler, Btrfs ise kararı sonra değiştirmenize izin verir.

RAID ve Dayanıklılık: En Kritik Ayrım#

Bu bölüm, bu yazıdaki tek en önemli bilgi. Btrfs'in raid1 ve raid10 profilleri olgun kabul edilir ve üretimde yaygın olarak kullanılır. Buna karşılık Btrfs'in parite tabanlı raid5 ve raid6 profilleri hâlâ üretim için güvenli sayılmaz; write hole olarak bilinen, güç kesintisi sırasında parite ile veri arasında tutarsızlık oluşabilen bir sorun sınıfı vardır ve çekirdek belgeleri bu profiller için açık uyarı içerir.

ZFS tarafında ise parite RAID (raidz1, raidz2, raidz3) tasarımın merkezinde yer alır ve write hole problemi copy-on-write yapısı sayesinde mimari olarak ortadan kalkmıştır. Yani "beş diskim var, alan verimliliği istiyorum, parite kullanmak zorundayım" diyorsanız ZFS pratikte tek makul seçenektir.

Her iki tarafta da düzenli doğrulama şart. Btrfs'te btrfs scrub start /mnt/veri, ZFS'te zpool scrub tank komutu tüm blokları okuyup sağlama toplamlarıyla karşılaştırır. Diskin fiziksel olarak ölmeye başladığını ise ikisi de söylemez; onun için SMART verisine bakmanız gerekir ve yöntemi disk arızası tespiti, SMART ve RAID yazısında bulabilirsiniz.

Snapshot ve Subvolume Davranışı#

ZFS'te snapshot bir dataset'e aittir ve varsayılan olarak salt okunurdur. Yazılabilir bir kopya istiyorsanız zfs clone ile klon oluşturursunuz. Snapshot'lar dataset'in içindeki gizli .zfs/snapshot/ dizininden doğrudan gezilebilir, bu da "sadece şu dosyanın dünkü hâlini istiyorum" senaryosunu çok pratik hale getirir.

Btrfs'te ise karşılık gelen kavram subvolume'dur ve snapshot aslında bir subvolume'un başka bir subvolume kopyasıdır. Varsayılan olarak yazılabilirdir; salt okunur istiyorsanız -r bayrağını eklersiniz. Salt okunur snapshot, btrfs send ile artımlı çoğaltma yapabilmenin de ön koşuludur:

# Subvolume oluştur
btrfs subvolume create /mnt/veri/web

# Salt okunur snapshot al
btrfs subvolume snapshot -r /mnt/veri/web /mnt/veri/.snap/web-2026-08-25

# Snapshot'ları listele
btrfs subvolume list /mnt/veri

# Başka bir makineye artımlı gönder
btrfs send -p /mnt/veri/.snap/web-2026-08-24 /mnt/veri/.snap/web-2026-08-25 \
  | ssh [email protected] btrfs receive /yedek/web

Pratikte iki fark hissedilir. Btrfs'in subvolume yapısı daha esnektir, bir subvolume'u doğrudan bağlayabilir ve / dizinini snapshot alıp önyükleme sırasında eski snapshot'a dönebilirsiniz; bu, sistem güncellemesi geri alma senaryosunu Btrfs'te çok güçlü kılar. ZFS tarafında ise alan muhasebesi daha şeffaftır: zfs list -o space bir snapshot'ın gerçekten kaç bayt tuttuğunu net söyler, Btrfs'te aynı sorunun cevabı btrfs filesystem usage çıktısında daha dolaylıdır.

Sıkıştırma, Performans ve Kaynak Kullanımı#

Sıkıştırmada ikisi de güçlü. Btrfs bağlama seçeneği olarak compress=zstd:3 biçiminde ayarlanır, ZFS ise dataset özelliği olarak compression=lz4 ya da compression=zstd alır. İkisinde de sıkışmayan veri erken tespit edilip olduğu gibi yazılır, dolayısıyla sıkıştırmayı açmak neredeyse her zaman doğru karardır.

# Btrfs: bağlama seçeneği olarak (fstab satırı)
# UUID=... /mnt/veri btrfs compress=zstd:3,noatime,subvol=@veri 0 0

# ZFS: dataset özelliği olarak
zfs set compression=zstd tank/web
zfs set atime=off tank/web

Kaynak kullanımında en görünür fark bellektir. ZFS'in ARC önbelleği boştaki RAM'i agresif biçimde kullanır; baskı geldiğinde bırakır ama izleme araçlarında bellek dolu görünür ve bu birçok kişiyi tedirgin eder. Btrfs çekirdeğin genel sayfa önbelleğini kullandığı için davranışı Linux yöneticisine daha tanıdık gelir ve küçük bellekli makinelerde daha az sürprizle çalışır.

Performansta tek bir kazanan yok. Sıralı büyük okuma-yazmalarda ikisi de disk hızına yaklaşır. Küçük ve senkron yazmalarda ZFS'in ayrı bir amaç için tasarlanmış SLOG aygıtı ekleyebilme yeteneği avantaj sağlar. Yoğun rastgele yazma alan veritabanı dosyalarında Btrfs'te copy-on-write parçalanmaya yol açabilir; bu yüzden veritabanı dizinlerinde chattr +C ile copy-on-write kapatmak yaygın bir uygulamadır. Aynı sorunun ZFS'teki karşılığı recordsize ayarını veritabanının sayfa boyutuna eşitlemektir.

Kurulum, Lisans ve Dağıtım Desteği#

Bu başlık, karar üzerinde beklediğinizden daha fazla etki eder. Btrfs Linux çekirdeğinin bir parçasıdır; hiçbir şey kurmanız gerekmez, mkfs.btrfs zaten oradadır ve çekirdek güncellemesi sonrası ek bir işlem yoktur. ZFS ise CDDL lisansı nedeniyle çekirdeğe dahil edilemez, ayrı bir modül olarak kurulur ve genellikle DKMS ile her çekirdek güncellemesinde yeniden derlenir.

# Btrfs: kurulum gerekmez, doğrudan biçimlendir
mkfs.btrfs -L veri -d raid1 -m raid1 /dev/sdb /dev/sdc
mount -o compress=zstd:3,noatime /dev/sdb /mnt/veri

# ZFS: önce modül kurulur
apt install -y zfsutils-linux
zpool create -o ashift=12 tank mirror /dev/sdb /dev/sdc

Pratikteki sonucu şudur: kök dosya sistemini ZFS üzerine kurup çekirdeği güncellediğinizde, modül derlenmezse sistem açılmaz. Bu senaryo nadirdir ama olur ve konsol erişimi gerektirir. Btrfs'te böyle bir risk sınıfı hiç yoktur. Uzaktaki bir VDS üzerinde konsol erişiminiz kısıtlıysa bu risk farkı gerçekten dikkate değer. Öte yandan birden fazla fiziksel diske doğrudan eriştiğiniz bir dedicated sunucu üzerinde ZFS'in parite RAID olgunluğu ağır basar.

Hangi Senaryoda Hangisini Seçmeli#

Karar tablosunu şöyle özetleyebilirim:

Her iki tarafta da kaçınmanız gereken ortak nokta şu: hiçbiri yedek yerine geçmez. Snapshot aynı diskte durur; sunucu ölürse snapshot da ölür. Bağımsız bir kopya için farklı teknolojiyle ikinci bir katman kurun, mesela Borg ile sunucu yedekleme yazısındaki yaklaşım her iki dosya sisteminin üzerinde de sorunsuz çalışır.

Sık Yapılan Hatalar#

Btrfs raid5 ile üretime çıkmak. Alan verimliliği cazip görünür ama write hole riski gerçektir ve genellikle en kötü anda, güç kesintisinden sonra ortaya çıkar. Parite istiyorsanız ZFS raidz kullanın.

Btrfs'te "disk dolu" hatasını yanlış okumak. Btrfs veri ve meta veri alanını ayrı ayrı ayırır; df boş alan gösterirken meta veri alanı dolduğu için yazma başarısız olabilir. Doğru komut btrfs filesystem usage /mnt/veri çıktısına bakmak ve gerekirse btrfs balance çalıştırmaktır.

ZFS havuzunu donanımsal RAID kartının arkasına koymak. Kart diskleri gizler, ZFS bozuk bloğun ikinci kopyasına ulaşamaz ve onaramaz. Kartı HBA moduna alın.

Snapshot biriktirip unutmak. İkisinde de snapshot sayısı arttıkça alan muhasebesi karmaşıklaşır ve silmeler yavaşlar. Otomatik bir saklama politikası kurun; günlük yedi, haftalık dört, aylık altı gibi.

Disk aygıt adlarına güvenmek. /dev/sdb yeniden başlatmada değişebilir. Havuzu /dev/disk/by-id/ altındaki kalıcı isimlerle kurun. Disk bölümleme ve aygıt isimlendirme konusunda temel bilginiz eksikse disk bölümleme, fdisk ve parted yazısı iyi bir başlangıç noktasıdır.

Sıkça Sorulan Sorular#

Btrfs üretimde kullanılabilir mi#

Evet, ama profil seçimine dikkat ederek. Tek disk, raid1 ve raid10 profilleri uzun süredir üretimde yaygın olarak kullanılıyor ve büyük dağıtımlar tarafından varsayılan seçenek olarak sunuluyor. Buna karşılık raid5 ve raid6 parite profilleri hâlâ önerilmiyor. Yani "Btrfs üretime hazır mı" sorusunun cevabı hangi RAID profilini kullanacağınıza bağlı.

ZFS mi Btrfs mi daha hızlı#

Tek bir cevabı yok, iş yüküne bağlı. Sıralı büyük dosya aktarımlarında ikisi de disk hızının sınırına yaklaşır ve aradaki fark ölçüm hatası seviyesinde kalır. Yoğun senkron yazma yapan veritabanlarında ZFS'in SLOG aygıtı ekleyebilme yeteneği avantaj sağlar. Küçük bellekli makinelerde ise Btrfs, ARC'nin bellek baskısı olmadığı için daha öngörülebilir davranır.

Btrfs'ten ZFS'e veri taşımak zor mu#

Yerinde dönüştürme mümkün değil, veriyi kopyalamanız gerekir. En temiz yol yeni havuzu kurup rsync -aHAX ile veriyi aktarmak, sonra bağlama noktalarını değiştirmektir. Snapshot geçmişiniz taşınmaz; sadece güncel veri gider. Bu yüzden geçişi planlarken kesinti penceresi ayırın ve eski havuzu, yeni yapının birkaç gün sorunsuz çalıştığını görene kadar silmeyin.

Snapshot yedek yerine geçer mi#

Hayır. Hem Btrfs hem ZFS snapshot'ları aynı dosya sistemi içinde durur. Disk arızası, denetleyici hatası, sunucunun tamamen kaybı ya da root yetkisi kazanan bir saldırgan durumunda snapshot'lar da kaybolur. Snapshot çok hızlı bir geri alma aracıdır; gerçek yedek, başka bir makinede veya başka bir lokasyonda duran bağımsız kopyadır.

Hangisi daha az RAM tüketir#

Genel kullanımda Btrfs. Çekirdeğin standart sayfa önbelleğini kullandığı için ek bir bellek yönetimi katmanı yoktur. ZFS'in ARC önbelleği boştaki belleği kullanır ve baskı altında geri verir, ama izleme araçlarında bellek dolu görünür. ZFS'i düşük bellekli bir makinede kullanacaksanız zfs_arc_max ile tavan koyun ve veri tekilleştirmeyi kesinlikle açmayın.

Kök dosya sistemi olarak hangisini kurmalıyım#

Snapshot alıp güncelleme sonrası geri dönebilmek en büyük önceliğinizse Btrfs daha az sürtünmeli bir deneyim sunar; subvolume yapısı sayesinde önyükleme menüsünden eski bir snapshot'a dönmek yaygın bir kalıptır ve çekirdek modülü derlenmesi gerekmez. ZFS'i kök olarak kurmak da mümkündür ve iyi çalışır, ancak çekirdek güncellemesi sonrası modülün derlenememesi gibi bir risk sınıfı ekler; uzak sunucuda konsol erişiminiz sınırlıysa bunu hesaba katın.

Kapanış#

Btrfs ve ZFS aynı problemi çözen iki olgun cevap, ama ağırlık merkezleri farklı. Btrfs esneklik tarafında güçlü: kurulum gerektirmez, disk ekleyip çıkarabilirsiniz, küçültme yapabilirsiniz ve kök dizini snapshot alıp geri dönme senaryosu çok rahattır. ZFS ise dayanıklılık ve öngörülebilirlik tarafında güçlü: parite RAID olgun, alan muhasebesi net, ayar seçenekleri derin. Aklınızda kalması gereken üç şey şu: parite RAID gerekiyorsa ZFS seçin, disk kompozisyonunuzun değişme ihtimali yüksekse Btrfs seçin, hangisini seçerseniz seçin sıkıştırmayı açın ve düzenli scrub çalıştırın.

Bu yapıları kendi elinizle kurmak için tam root erişimi gerekir; birden fazla fiziksel diske doğrudan erişmek istiyorsanız dedicated sunucu, daha küçük ölçekte denemek isterseniz VDS paketlerimiz uygun bir zemin sunar. Havuz kurulumunu, scrub takvimini ve snapshot saklama politikasını sizin yerinize kurgulamamızı isterseniz sunucu yönetimi hizmetimiz devreye girer; dosya sisteminden bağımsız ikinci bir kopya için de yedekleme çözümlerimize bakabilirsiniz.