ZFS Nedir? Zettabyte File System Kurulumu, Optimizasyonu ve Ayarları

Depolama dünyası, veri bütünlüğünü öncelik sayan sistem yöneticileri için acımasızdır. Sessiz veri bozulması (silent data corruption) bir gecede yıllık emeğinizi yok edebilir. Tam da bu sebeple kurumsal projelerde ZFS (Zettabyte File System) kullanıyorum. Üstelik bu sistemi 10 yılı aşkın süredir tercih ediyorum.

Bugün size bu yapının neden sıradan bir dosya sistemi olmadığını anlatacağım. Üstelik 2026 itibarıyla OpenZFS 2.4 ve sonrası yeni özellikleri de taze taze harmanlayacağım.

ZFS nedir sorusu aslında bir çırpıda cevaplanacak kadar basit değildir. Çünkü bu yapı hem bir dosya sistemi hem de birim yöneticisi görevlerini tek katmanda birleştirir. 128-bit adresleme sayesinde teorik zettabayt kapasite sunar. Sıradan bir ev kullanıcısı bile farkında olmadan bu gücü cebine koyar.

Birçok kişi depolama tercihlerini fiyat-performans ekseninde yapar. Oysa veri kaybı senaryosu yaşadıktan sonra herkes keşke daha güvenli bir yapı seçseydim der.

İşte tam bu noktada copy-on-write dosya sistemi mimarisi ile ZFS, rakiplerinden ayrılır. Çünkü veriyi yazarken asla üzerine yazmaz. Bu sayede fidye yazılımı dayanıklılığı (ransomware resilience) sağlar.

Günümüzde yazılım tanımlı depolama (software-defined storage) stratejileri veri merkezlerini şekillendiriyor. ZFS ise bu akımın öncüsü olarak 2026’da hala tahtını koruyor.

ZFS (Zettabyte File System) Nedir? Temel Tanım ve Tarihçe

ZFS Dosya Sisteminin Hikayesi: Sun Microsystems’ten OpenZFS’e

Bu hikaye 2000’lerin başında Sun Microsystems laboratuvarlarında başladı. Jeff Bonwick liderliğindeki ekip, Solaris işletim sistemine devrim niteliğinde bir depolama katmanı kazandırmak istiyordu.

Geliştiriciler 2005 yılında ZFS kaynak kodunu CDDL lisansı ile açıkladı. Dahası mühendisler bu yapıyı ilk günden beri işlemsel tasarladı. Yani, transactional file system olan bir dosya sistemidir.

Sun’ın Oracle tarafından satın alınmasıyla süreç çatallandı. Oracle kendi kapalı sürümünü geliştirirken, topluluk Illumos çatısı altında OpenZFS projesi ni başlattı.

Bugün FreeBSD ve Linux üzerindeki ZFS On Linux sürümlerini kullanıyoruz. Üstelik bu sistemler ile macOS bile ilgili topluluk sürümünden besleniyor. 2026 itibarıyla OpenZFS 3.0 sürüm notları, artık tamamen topluluk sürümü yol haritası ile ilerlediğimizi kanıtlıyor.

ZFS’in asıl doğal ortamı BSD ailesi içinde yeşerdi. FreeBSD, NetBSD, OpenBSD hep aynı kökten geliyor. Lafı dolandırmayacağım, bu aile olmasaydı OpenZFS bu kadar özgür büyüyemezdi.

Geliştiriciler ilk yıllarda bu yapıyı sadece Solaris dosya sistemi olarak adlandırıyordu. Ancak topluluğun çabalarıyla FreeBSD 8.0’da native destek geldi. Linux tarafında ise lisans uyumsuzluğu nedeniyle yıllarca DKMS modülü ile çalışmak zorunda kaldık. Neyse ki Ubuntu 20.04’ten beri yerleşik destek mevcut.

ZFS Sadece Bir Dosya Sistemi mi? Volume Manager Entegrasyonu

Klasik Linux sistemlerinde LVM ile ext4’ü ayrı ayrı yönetirsiniz. Oysa bu yapı, dosya sistemi ve LVM entegrasyonu nu doğuştan getirir. Aynı komut satırından hem storage pool yönetimini hem de dataset ve zvol yapılarını kontrol edersiniz.

Pratikte ne anlama gelir? Diyelim ki 10 diskiniz var. LVM ile önce fiziksel volume, sonra volume group, ardından logical volume oluşturursunuz. Yetmez, üzerine dosya sistemi kurarsınız. Burada ise tek bir zpool create komutuyla tüm katmanları aynı anda halledersiniz. Havuz tabanlı depolama yaklaşımı sayesinde diskleri tek tek değil, havuz bütünü olarak yönetirsiniz.

Esnek depolama mimarisi arayanlar için bu entegrasyon biçilmiş kaftandır. Örneğin bir sanal makine için ham disk benzeri bir aygıt lazımsa, zvol oluşturursunuz. Bu sanal blok aygıtı tıpkı bir iSCSI target gibi davranır. Üstelik üzerinde anlık görüntü yedekleme, sıkıştırma gibi tüm nimetlerden faydalanırsınız.

ZFS Dosya Sistemi Çalışma Mantığı: Copy-on-Write & Veri Bütünlüğü

Copy-on-Write (CoW) ile Veri Güvenliği

CoW mimarisi, veriyi güncellerken eski blokları asla ezmez. Yeni veriyi her zaman boş bir alana yazar. Ardından işaretçileri atomik olarak değiştirir. Bu sayede yazma işlemi yarıda kesse bile tutarlılık bozulmaz.

Mesela bir elektrik kesintisi anında klasik sistemlerde dosya bozulur. Ancak burada ya eski sürüm ya da yeni sürüm eksiksiz kalır. Ben bunu bir keresinde UPS’in patladığı bir sunucuda canlı canlı deneyimledim. Veri tabanı dosyaları tamamen sağlamdı. O gün anladım ki write hole koruması gerçekten işe yarıyor.

Bu mekanizma aynı zamanda snapshot replication için temeldir. Çünkü bir anlık görüntü aldığınızda sadece işaretçileri dondurursunuz. Ek alan tüketimi neredeyse sıfırdır. Sistem daha sonra değişen blokları yeni yerlere yazar.

Üstelik bu yapı fidye yazılımı saldırılarında eski snapshot’a dönüşü mümkün kılar. Blok klonlama teknolojisi de bu sayede çalışır. Aynı verinin kopyasını ek alan harcamadan oluşturursunuz. OpenZFS 2.2’de gelen bu yenilik, sanal makine klonlama için devrim niteliğindedir.

Checksum ve Bit Rot (Veri Bozulması) Koruması

Sistem, her veri bloğunu diske yazmadan önce 256-bit checksum ile imzalar. Üstelik okuma sırasında bu checksum doğrulamayı tekrar yapar. Eğer bir uyumsuzluk varsa, veri bozulmasını anında tespit eder. Ardından yedek kopyadan otomatik düzeltme gerçekleştirir.

Sektördeki insanlar bu teknolojiyi bit rot koruması olarak adlandırır. Manyetik disklerdeki bozuk sektörler zamanla veriyi kemirir.

Sessiz veri bozulmasını (silent data corruption) yıllarca fark edemezsiniz. Ta ki o dosyaya ihtiyacınız olana kadar. ZFS ise düzenli scrub (atlama) işlemleriyle tüm havuzu tarar. Bozuk blokları tespit edip sağlam kopyayla onarır. Ben her ay en az bir kez scrub çalıştırırım.

Blok seviyesinde doğrulama, yazılımsal RAID’in bile ötesine geçer. Donanım RAID kartları sadece şerit bütünlüğünü kontrol eder. Ama dosya içindeki bozulmayı göremez.

Oysa bu dosya sistemi mimarisi her IO’da checksum yapar. Üstelik RAID-Z dinamik yapısı sayesinde değişken şerit boyutu kullanır. Bu da küçük dosyalarda alan israfını önler.

ZFS Temel Yapı Taşları: zpool, vdev, dataset ve zvol

zpool (Depolama Havuzu) Nedir?

Zpool, fiziksel diskleri bir araya getirerek oluşturduğunuz depolama havuzudur. Bu havuz tabanlı depolama nın kalbidir. Diskleri tek tek biçimlendirmez, hepsini ortak bir havuza katarsınız. Aslında havuz kapasitesi, tüm VDEV’lerin toplamıdır.

Ben genellikle zpool create tank mirror /dev/sda /dev/sdb gibi basit komutlarla başlarım. Ama kurumsal ölçekte ZFS uygulama zorlukları arasında doğru VDEV tasarımı gelir.

Her VDEV bir RAID-Z grubu olabilir. Havuza sonradan VDEV eklemek mümkündür, ancak bir VDEV içindeki disk sayısını değiştiremezsiniz.

• Mirror: En yüksek IOPS, %50 alan verimliliği. Kritik VM’ler için idealdir.
• RAID-Z1: 1 disk toleranslı, alan verimliliği yüksek. Ev NAS için uygundur.
• RAID-Z2: 2 disk toleranslı, kurumsal ortamın standartıdır.
• RAID-Z3: 3 disk toleranslı, çok yüksek güvenlik isteyen arşivler içindir.

Havuz oluştururken ashift değerine dikkat edin. 4K sektörlü modern disklerde ashift=12 kullanmalısınız. Aksi halde sektör hizalaması bozulur. Bu da yazma amplifikasyonu nu artırır.

Özellikle flash bellek ömrü için bu ölümcüldür. Bir diğer kritik konu ise pool capacity threshold (havuz kapasite eşiği) değeridir. Yani havuz %80 doluluğa ulaştığında performans ciddi şekilde düşer.

vdev, dataset ve zvol: Ne işe yararlar?

VDEV, havuzun temel yapı taşıdır. Her VDEV fiziksel disk grubudur. Havuza birden fazla VDEV eklerseniz, IOPS toplamı artar.

Çünkü yazmaları tüm VDEV’lere dağıtır. Bu yüzden yüksek performanslı sistemlerde çok sayıda mirror VDEV kullanırım.

Dataset ise bu depolama havuzu üzerindeki dosya sistemi bölümüdür. Tıpkı normal bir dizin gibi kullanırsınız. Ancak kendi kotası, sıkıştırma ayarı ve recordsize değeri olabilir.

Örneğin, bir veritabanı için recordsize=16K ayarı yaparsınız. Medya dosyaları için recordsize=1M kullanırsınız. Bu esneklik, iş yükü profilleme ve kapasite planlamasını mükemmelleştirir.

Zvol ise bir sanal blok aygıtıdır. İşletim sistemine /dev/zvol/tank/disk1 gibi bir blok cihaz sunar. Üzerine ext4, NTFS veya doğrudan iSCSI target olarak kullanabilirsiniz.

Dataset ile zvol arasındaki temel fark: dataset dosya sistemi sunar, zvol ise ham blok aygıtı. Sanal makine depolamada genellikle zvol tercih ederiz. Çünkü thin provisioning (ince provizyonlama) ile alan kazanırız. Birim blok boyutu (volblocksize) ayarı da burada kritiktir.

ZFS vs Rakipleri: Btrfs, EXT4, LVM ve XFS Karşılaştırması

ZFS mi Btrfs mi? Hangi Senaryoda Hangisi Kazanır?

Btrfs de bir CoW dosya sistemidir. Yerleşik anlık görüntü ve sıkıştırma sunar. Ancak RAID5/6 yazma deliği (write hole) sorununu yıllarca çözemedi.

Oysa ZFS, RAID-Z dinamik yapısı ile bu sorunu kökünden halleder. Bu nedenle kritik üretim ortamlarında ben her zaman OpenZFS’ten yanayım.

Btrfs’in en büyük avantajı Linux çekirdeğinde yerleşik olmasıdır. DKMS derdi yoktur. Ama veri bütünlüğü denetimi ve onarım yetenekleri daha zayıftır.

Özellikle metadata bozulması durumunda kurtarma işlemleri karmaşıklaşır. Halbuki bu yapıda zpool import ile çoğu sorundan kurtulabilirsiniz. Evet, ZFS öğrenme eğrisi daha diktir. Ancak bir kez aştınız mı arkanıza bakmazsınız.

Evde NAS kullanımı için Btrfs yeterli olabilir. Fakat kurumsal depolama çözümü arıyorsanız, ZFS’in veri dayanıklılığı rakipsizdir.

Ayrıca ZFS native encryption (AES-256-GCM) desteği Btrfs’te yok. Yerleşik ACL desteği ve delegasyon yetenekleri de cabası.

ZFS vs EXT4 ve LVM: Performans ve Güvenlik Karşılaştırması

EXT4 ailesi dosya sistemlerinin, basitliği ve yüksek hızıyla biliyoruz. Özellikle tek diskli sistemlerde düşük gecikme sunar. Ancak ne veri bütünlüğü denetimi ne de yerleşik RAID desteği vardır.

LVM ile birleştirdiğinizde anlık görüntü alabilirsiniz. Fakat bu, gerçek bir CoW anlık görüntüsü değildir, yavaştır.

Performans testlerinde EXT4 ham hızda öne çıkar. Çünkü ekstra checksum hesaplaması yapmaz. Ancak ZFS, ARC ve L2ARC gibi akıllı önbellek katmanları ile okuma performansını şaşırtıcı derecede artırır.

Örneğin, 64 GB RAM’li bir sunucuda ARC, sık kullanılan veriyi bellekte tutar. EXT4 ise page cache’e güvenir, o da daha az optimize çalışır. Güvenlik cephesinde ise ZFS tartışmasız kazanır.

ZFS vs XFS: Büyük Veri ve Veritabanı İş Yüklerinde Kıyas

XFS, büyük dosyalar ve yüksek paralellik için tasarladılar. Özellikle Red Hat ekosisteminde varsayılandır. Ancak CoW ve veri bütünlüğü denetimi özellikleri yoktur. Büyük veri ortamlarında saf IO bant genişliği isteyenler XFS’i tercih eder.

Buna rağmen ZFS, recordsize optimizasyonu ile veritabanı performansında XFS’i yakalar hatta geçer. PostgreSQL tuning için recordsize=8K veya 16K, ashift=12 yapmak gerekir.

Ayrıca özel metadata cihazı (special VDEV) kullanarak metadata erişimini SSD’lere kaydırırsanız, sorgu performansı uçar. Ben bir PostgreSQL kümesini bu şekilde optimize ettiğimde %40 hız artışı gördüm.

XFS’in bir diğer avantajı çevrimiçi büyüme ve küçülme yeteneğidir. ZFS ise havuz esnekliği konusunda daha kısıtlıdır. Ancak yeni disk ekleyerek büyüme mümkündür.

Ayrıca ZFS sıkıştırma (LZ4, ZSTD) sayesinde XFS’e göre çok daha az alan tüketir. Bulut maliyet düşürme stratejilerinde bu ciddi fark yaratır.

ZFS Dosya Sistemi Nasıl Kurulur? (Ubuntu, FreeBSD & Proxmox Örnekleri)

Ubuntu 22.04 / 24.04 Üzerinde ZFS Kurulumu

Linux Ubuntu sisteminde ZFS kurmak artık çocuk oyuncağı. İlk olarak sistemi güncelleyin: sudo apt update && sudo apt upgrade -y. Ardından gerekli paketleri yükleyin: sudo apt install zfsutils-linux -y.

Bundan sonra çekirdek modülü otomatik yüklenecektir. DKMS modülü derdini dert etmeyin, Ubuntu bunu halleder.

1. lsblk ile diskleri listeleyin.
2. sudo zpool create -o ashift=12 mypool mirror /dev/sdb /dev/sdc komutuyla ayna havuz oluşturun.
3. zpool status ile havuz durumunu kontrol edin.
4. sudo zfs create mypool/data ile dataset oluşturun.
5. sudo zfs set compression=lz4 mypool/data ile sıkıştırmayı açın.

Artık verileriniz /mypool/data altında güvende. Ayrıca fstab’a eklemeye gerek yoktur. ZFS bağlama noktalarını otomatik yönetir.

Kalıcı olması için sudo zpool set cachefile=/etc/zfs/zpool.cache mypool demeniz yeterlidir. Böylece sistem, yeniden başlatma esnasında havuzu otomatik olarak içe aktarır.

Proxmox’ta ZFS Havuzu Oluşturma ve ashift Ayarı

Proxmox VE, ZFS ile mükemmel entegre çalışır. Kurulum sırasında disk seçiminde ZFS (RAID0/1/10) seçebilirsiniz. Ancak ince ayar isteyenler için manuel havuz oluşturma öneririm. Önce tüm diskleri HBA kartı üzerinden IT modda Proxmox’a gösterin.

Ardından konsola geçin: zpool create -o ashift=12 rpool mirror /dev/disk/by-id/ata-disk1 /dev/disk/by-id/ata-disk2. Disk kimliği kullanmak, fiziksel sıra değişikliğinde sorun çıkarmaz.

Modern SSD ve HDD’ler 4K sektörlüdür. Bu yüzden ashift=12 kullanın. Eğer eski 512B disklerle karışık kullanıyorsanız, en düşük sektör boyutuna göre ayarlayın. Yanlış ashift, performansı %50’lere varan oranda düşürür ve SSD aşınması nı artırır.

Havuzdan sonra VM depolama için zvol oluşturun: zfs create -V 50G rpool/vm-100-disk-1. volblocksize’ı unutmayın: zfs set volblocksize=16k rpool/vm-100-disk-1.

Proxmox arayüzünde bu depoyu ekleyip kullanabilirsiniz. Ayrıca L2ARC için NVMe SSD eklemek isterseniz: zpool add rpool cache /dev/nvme0n1.

FreeBSD’de ZFS Yapılandırması

FreeBSD işletim sistemi, ZFS’nin ana vatanıdır. Kurulum sırasında otomatik ZFS yapılandırması sunar. Ancak ben manuel kurulumu tercih ederim. Önce disklere GPT tablosu yazın: gpart create -s gpt ada0. Ardından önyükleme bölümü ve ZFS bölümü oluşturun.

Kurulum sırasında bsdinstall size ZFS havuzu kurma sihirbazı sunar. Orada mirror veya raidz seçebilirsiniz. Kurulum sonrası ilk iş /boot/loader.conf dosyasına zfs_load="YES" eklemektir.

FreeBSD 14’te OpenZFS doğrudan çekirdekte yer alır. ZFS On Linux kadar olmasa da FreeBSD üzerindeki performans oldukça tatminkardır. Özellikle ARC yönetimi FreeBSD’de daha stabildir. Ayrıca boot ortamı (boot environment) desteği sayesinde sistem güncellemelerinde geri dönüş kolaydır.

ZFS Performans ve Donanım Seçiminin Sırları

RAM İhtiyacı: ARC, L2ARC ve Dedup RAM Hesaplama Formülü

ZFS, önbellek katmanı olarak ARC (Adaptive Replacement Cache) kullanır. ARC, veriyi RAM’de tutar ve okuma performansını artırır. Varsayılan olarak sistem belleğinin yarısını kullanır. Ancak bu değer ayarlanabilir: echo 8589934592 >> /sys/module/zfs/parameters/zfs_arc_max ile 8 GB sınırı koyabilirsiniz.

“ZFS çok RAM yer” efsanesi kısmen doğrudur, ama aslında ARC ihtiyacı iş yüküne bağlıdır. Salt dosya sunucusu için 4 GB yeterli olabilir.

Ancak tekilleştirmeyi (deduplication) açarsanız RAM ihtiyacınız katlanır. DDT (Deduplication Table) her bir tekilleştirilmiş blok için RAM’de giriş tutar. Genel kural: Her 1 TB veri için yaklaşık 1-5 GB RAM (DDT boyutu).

ECC RAM kullanımını şiddetle tavsiye ederim. Çünkü bellekteki bir bit hatası, checksum hesaplamasını bozup sağlam veriyi hatalı gösterebilir. Ama “ECC zorunlu” efsanesini sonra çürüteceğim. Yine de bütçeniz varsa ECC RAM kullanın.

L2ARC ise, ARC’den düşen verileri NVMe SSD’de saklar. Ancak L2ARC, RAM’de indeks tutar. Bu nedenle düşük RAM’li sistemlerde L2ARC eklemek, ARC’den çalma yapar ve performansı düşürür.

HBA Kartı Seçimi ve IT Mode Zorunluluğu (RAID Kartı Passthrough Riskleri)

ZFS, diskleri doğrudan görmek ister. Donanım RAID kartı araya girerse, ZFS’in checksum ve kurtarma mekanizmaları çalışmaz.

Üstelik RAID kartı passthrough ZFS riskleri büyüktür; kart önbelleği veri kaybına yol açabilir. Bu yüzden HBA (Host Bus Adapter) kartını IT Mode (Initiator Target) olarak kullanmalısınız.

Ben yıllardır LSI 9211-8i veya 9300-8i gibi kartları IT moda flaşlayıp kullanırım. Ucuz ve güvenilirdirler. Ayrıca PLP (Power Loss Protection) özelliği olan SSD’lerle kullanıldığında SLOG performansı efsane olur.

HBA seçerken mutlaka ZFS ile uyumlu sürücülere sahip olduğundan emin olun. FreeBSD’de mpr, Linux’ta mpt3sas sürücüsü genelde sorunsuzdur.

SLOG ve ZIL: PLP (Power Loss Protection) SSD Olmazsa Olmaz!

ZIL (ZFS Intent Log), senkron yazmaları önce geçici olarak kaydeder. Sistem varsayılan olarak bu işlemi havuzdaki disklerde yapar. Dolayısıyla bu yöntem oldukça yavaştır.

Performansı artırmak için ayrı bir SLOG (Separate Intent Log) cihazı ekleyebilirsiniz. SLOG, düşük gecikmeli, yüksek dayanıklılıklı bir SSD olmalıdır.

SLOG için kullanacağınız SSD’de mutlaka PLP (güç kesintisi koruması) olmalı. PLP, ani elektrik kesintisinde veri kaybını önler.

Intel Optane bu iş için mükemmeldir. 58 GB Optane 800P bile SLOG için yeterlidir. Ben birçok kurulumda Optane ile senkron yazma performansını 10 kat artırdım. Standart bir SSD’yi SLOG yaparsanız, güç kaybında son yazmalar uçabilir.

L2ARC Yapılandırması: Ne Zaman Kullanılır, Neden Bazen Yavaşlatır?

L2ARC, RAM’deki ARC’nin diske taşan ikinci seviye önbelleğidir. Uzmanlar bu işlem için genellikle NVMe SSD tercih eder. Ancak her durumda faydalı değildir.

ARC zaten yeterince büyükse L2ARC gereksizdir. Üstelik L2ARC, RAM’de indeks tutar. Bu nedenle düşük RAM’li sistemlerde L2ARC eklemek, ARC’den çalma yapar ve performansı düşürür. Ben L2ARC’ı ancak RAM max. yapılandırıldıktan sonra, ARC isabet oranı hala düşükse eklerim.

L2ARC için NVMe önerileri: Yüksek dayanıklılık (TBW) ve düşük gecikme önemli. Samsung PM983, Intel P4510 gibi kurumsal SSD’ler idealdir.

Kalıcı L2ARC (persistent L2ARC) özelliği yeniden başlatmalarda önbelleğin korunmasını sağlar. Bu, OpenZFS 2.1 ile geldi ve büyük kolaylık. L2ARC neden yavaş sorusu sık gelir. Sebep: besleme hızı sınırlıdır. Ani okuma yükünde ARC’den tahliye edilen bloklar L2ARC’a yazılırken gecikme yaşanır.

ZFS Gerçek Dünya Kullanım Senaryoları (NAS, Veritabanı, Sanallaştırma, Bulut)

Evde NAS ve Medya Sunucularında ZFS (Zettabyte File System) Kullanımı

Evde Plex, Jellyfin veya dosya paylaşımı için ZFS idealdir. Özellikle RAID-Z1 veya mirror havuz ile veri kaybı derdinden kurtulursunuz.

Mesela 4 adet 4 TB diskle RAID-Z1 yapabilirsiniz. Bu sayede bir disk arızalansa dahi 12 TB alan kazanırsınız. Ayrıca sıkıştırma ile medya dosyalarında yer kazanırsınız.

• TrueNAS Scale: Ev NAS’ı için en popüler OpenZFS tabanlı işletim sistemi. Web arayüzü ile havuz yönetimi, SMB paylaşımı çok kolay.
• Snapshots: Yanlışlıkla silinen dosyaları anında kurtarır. Fidye yazılımına karşı immutable snapshot alın.
• Replikasyon: zfs send/receive ile harici diske veya buluta yedekleyin.
• Minimum RAM: 8 GB öneririm. ARC, sık kullanılan dosyaları önbellekleyerek akıcı medya oynatımı sağlar.

Dikkat edilecek nokta: Havuzu %80’den fazla doldurmamak. Ayrıca düzenli scrub çalıştırmak şart. Ben ayda bir kez scrub yapıyorum. Bu sayede yıllardır ev NAS’ımda veri kaybı yaşamadım. Ayrıca, fidye yazılımına karşı immutable snapshot alıp uzak sunucuya replike ediyorum.

Veritabanı Sunucuları (PostgreSQL / MySQL) İçin ZFS Optimizasyonu

Veritabanları için recordsize ayarı hayati önem taşır. PostgreSQL varsayılan sayfa boyutu 8KB’dir. Bu yüzden recordsize=8K kullanın. MySQL InnoDB için 16K idealdir.

Ayrıca veritabanı sunucusunda sync write ayarını doğru yapın. Veri kaybı istemiyorsanız sync=always, ama performans için SLOG şart. Ben genelde sync=standard bırakır, SLOG eklerim.

Bir diğer önemli nokta: metadata SSD (special VDEV). Veritabanı yoğun metadata erişimi yapar. Özel metadata cihazı kullanarak metadata’yı NVMe SSD’ye taşırsanız, sorgu performansı %200 artabilir. zpool add dbpool special mirror nvme0n1 nvme1n1 ile ekleyin.

Tabii ki bu SSD’lerin de PLP’li olması şart. Aksi halde metadata bozulması havuzu komple çökertebilir.

Sanal Makineler (Proxmox / VMware) ve ZFS

Proxmox ile ZFS entegrasyonu efsanedir. Her sanal makine için zvol oluşturur, üzerine qcow2 yerine ham disk sunarsınız.

Bu sayede snapshot alma, klonlama ve replikasyon inanılmaz hızlıdır. Proxmox’un yerleşik ZFS replikasyonu, felaket kurtarma için birebirdir.

VMware platformu ZFS teknolojisini doğrudan desteklemez. Ancak NFS paylaşımı veya iSCSI target olarak ZFS havuzunu sunabilirsiniz. Ben iSCSI hedefi için zvol + LIO (Linux) kullanırım. Performans oldukça iyidir.

Yine de mümkünse hipervizörün doğrudan ZFS desteklediği Proxmox veya TrueNAS SCALE tercih edin. Bir diğer avantaj: Block cloning ve Direct I/O sayesinde OpenZFS 2.4 ile VM klonlama ve yoğun G/Ç işlemleri önemli ölçüde hızlandı.

Container (Docker/Kubernetes) ve Bulut Ortamlarında ZFS

Docker, ZFS depolama sürücüsünü destekler. Docker’ı docker -s zfs ile başlatırsanız, her container katmanı bir dataset olur. Bu sayede hızlı commit ve rollback mümkündür.

Ayrıca yerleşik sıkıştırma ve snapshot özelliklerinden faydalanırsınız. Ben CI/CD ortamlarında bunu kullanıyorum, build süreleri kısalıyor.

Kubernetes için CSI (Container Storage Interface) sürücüsü mevcuttur. OpenEBS veya democratic-csi gibi projeler, ZFS havuzunu Kubernetes’e persistent volume olarak sunar.

Konteyner depolama katmanı ve CSI eklenti mimarisi sayesinde, StatefulSet uygulamaları yüksek performanslı yerel depolama alır. Üstelik anlık snapshot ile yedekleme ve klonlama yapabilirsiniz. Bulut ortamlarında (AWS, Azure, GCP) ZFS kullanmak mümkündür.

Bulut depolama maliyetini (AWS EBS) azaltmak isteyebilirsiniz. Şöyle ki sıkıştırma ve dedup yöntemiyle ciddi tasarruf sağlarsınız.

Örneğin AWS platformunda EC2 sistemine bağladığınız EBS birimlerini ZFS havuzuna dönüştürebilirsiniz. Bununla birlikte sıkıştırma özelliğini açtığınızda depolama giderlerinizi düşürürsünüz.

ZFS İnce Ayar ve Optimizasyon: recordsize, ashift, Sıkıştırma ve Dedup

recordsize ve ashift ile Performansı Katlayın

Recordsize, ZFS’in bir dosyayı bloklarken kullandığı maksimum boyuttur. Varsayılan 128K’dır. Veritabanı için 8K-16K, medya için 1M ayarlamak performansı dramatik artırır.

Örneğin, PostgreSQL veri dizini için: zfs set recordsize=8K mypool/pgdata. Bu sayede bir IO’da tam sayfa okunur, israf azalır.

• Veritabanları (PostgreSQL/MySQL): recordsize=8K veya 16K
• Medya Dosyaları (Plex/Jellyfin): recordsize=1M
• Genel Dosya Sunucusu: recordsize=128K (varsayılan)
• Sanal Makine zvol: volblocksize=16K veya 64K

ashift ise sektör hizalamasını belirler. Modern disklerde ashift=12 (4K) şart. Eski 512e disklerde ashift=9 kullanabilirsiniz.

Ancak yanlış ashift, özellikle SSD’lerde yazma amplifikasyonunu patlatır. Bu da flash bellek ömrü nü kısaltır. Bu yüzden kurulum öncesi disklerin sektör boyutunu kontrol edin: cat /sys/class/block/sda/queue/physical_block_size. Çıktı 4096 ise ashift=12 kullanın.

Sıkıştırma Algoritmaları: LZ4, ZSTD ve GZIP Karşılaştırması

ZFS, birçok sıkıştırma algoritması sunar. Seçiminiz performansı ve alan kazancını doğrudan etkiler. Aşağıdaki tablo, kendi laboratuvar ortamımda yaptığım test sonuçlarını gösterir.

Ben varsayılan olarak her dataset için lz4 kullanırım. Özellikle yüksek IOPS gerektiren ortamlarda idealdir. ZSTD sıkıştırma ise daha yüksek oran sağlar, fakat CPU kullanımı artar. Modern sunucularda bu sorun değildir.

Mesela bir web sunucusunda log dosyaları için ZSTD kullanıyorum, muazzam alan kazanıyorum. GZIP sıkıştırma ise en yavaş ve en yüksek CPU tüketicisidir. Genelde sadece soğuk arşiv verileri için uygundur.

Deduplication (Tekilleştirme): Gerçek Maliyet ve DDT Hesaplama

Deduplication, aynı blokları tek kopya olarak saklar. Bu, özellikle sanal makine imajları ve yedekleme ortamlarında büyük tasarruf sağlar. Ancak bedeli ağırdır. Sistem her benzersiz bloğun hash değerini RAM üzerinde saklar. Üstelik bu işlem için DDT (Deduplication Table) tablosunu kullanır. Bu da devasa RAM gerektirir.

Eğer illa kullanacaksanız, fast dedup özelliğini (OpenZFS 2.1+) araştırın. Biraz daha optimizedir; yine de RAM’i bol tutun. Ayrıca dedup’ı dataset bazında açın: zfs set dedup=on mypool/vms. Açıkçası tüm havuza açmak deliliktir.

Ayrıca DDT’nin RAM’de kalması için ARC’yi sınırlamayın. Yoksa sistem takılı kalır. Son tavsiye: Dedup yerine sıkıştırma kullanın. Çoğu senaryoda sıkıştırma, dedup kadar alan kazandırır, üstelik RAM cezası yoktur.

ZFS Sorun Giderme, Veri Kurtarma & Gelecek

ZFS Havuzu Çöktü! Veri Kurtarma Adımları (zpool import/export)

Havuz hatası paniğe gerek yok. İlk yapmanız gereken, veri kurtarma prosedürü ve havuz içe/dışa aktarma adımlarını sakinlikle uygulamak.

Önce disklerin fiziksel bağlantılarını kontrol edin. Ardından mevcut havuzları listeleyin: zpool import. Bu komut, içe aktarılabilecek tüm havuzları gösterir.

1. zpool import ile havuz adını bulun.
2. Havuz adını görürseniz, zpool import -f mypool ile zorla içe aktarın.
3. Eğer görünmüyorsa, zpool import -d /dev/disk/by-id mypool ile disk kimliğiyle deneyin.
4. Metadata bozulması durumunda: zpool import -F mypool ile son tutarlı gruba dönün.
5. En kötü senaryoda, Klennet ZFS Recovery gibi ticari yazılımlar kullanın.

Havuzu dışa aktarmak için zpool export mypool kullanın. Bu, havuzu güvenle sistemden ayırır. Taşınabilirlik sağlar. Ben sunucu değişikliklerinde her zaman export-import yaparım. Ayrıca düzenli yedekleme ve replikasyon şarttır.

%80 Doluluk Sınırı: Performans Neden Çöker ve Nasıl Önlenir?

ZFS havuzları %80 doluluğa ulaştığında, yazma performansı dramatik düşer. Çünkü CoW yapısı gereği, boş alan bulmak için disk kafası sürekli hareket eder. Fragmentasyon artar.

Bu durumu önlemek için havuz kapasite eşiğini sürekli izleyin: zpool list. Ben %70’te alarm kurar, %80’den önce mutlaka disk eklerim.

Doluluk sorunu yaşayanlar için çözüm: Yeni vdev ekleyin. zpool add mypool mirror sde sdf gibi. Ancak mevcut veriyi yeniden dengelemez.

Bu nedenle mümkünse havuzu baştan tasarlayın. Veya geçici olarak bazı datasetleri başka havuza taşıyın. ZFS send/receive bu iş için idealdir.

ZFS Fragmantasyonu Azaltma ve Autotrim Kullanımı

CoW dosya sistemlerinde fragmentasyon kaçınılmazdır. Özellikle sık güncellenen veritabanları veya VM imajları yüksek fragmentasyon oluşturur.

Bunu azaltmak için recordsize’ı iş yüküne uygun seçin. Ayrıca SSD kullanıyorsanız autotrim özelliğini açın: zpool set autotrim=on mypool. Bu, silinen blokları SSD’ye bildirir, performansı korur.

Fragmentasyonu görmek için zpool list -o name,frag kullanın. %50’nin üzerine çıktıysa, boş alan azalmış demektir. Çare: havuzu genişletmek veya veriyi yeni bir havuza zfs send ile taşımak.

Taşıma sırasında sistem verileri sıralı şekilde yazar. Sonuç olarak fragmentasyon sorununu tamamen ortadan kaldırırsınız. Ben bu yöntemi yılda bir kez uygularım. Ek olarak, ZFS üzerinde sanal makine çalıştırma durumunda, misafir işletim sisteminde TRIM/discard’ı etkinleştirin.

OpenZFS 3.0 Yol Haritası: Block Cloning ve Direct I/O

OpenZFS 3.0, 2026’da depolama dünyasında heyecan yaratıyor. Ama hemen belirteyim: Henüz kararlı sürüm olarak yayınlamadılar. En güncel kararlı sürüm OpenZFS 2.4.3 (Haziran 2026). 3.0, son dönemde deneysel olarak gelen özellikleri olgunlaştırıp tek bir çatı altında toplamayı hedefliyor.

Yol haritasının en dikkat çeken başlıkları şunlar:

• Block Cloning: Bu özellik aslında 2.2.0 ile geldi. Ancak geliştiricilerin bu özelliği 3.0 sürümünde daha da optimize etmesini bekliyoruz. Veriyi fiziksel olarak kopyalamadan sadece referans oluşturarak anında klonlama sağlıyor. VM ve konteyner ortamlarında devrim niteliğinde; anlık klon, anlık geri dönüş ve muazzam alan tasarrufu vaat ediyor.
• Direct I/O: Veritabanları gibi uygulamaların ARC önbelleğini bypass ederek doğrudan diske erişmesini sağlayacak. Büyük sıralı okuma/yazmalarda CPU yükünü azaltıp bant genişliğini artıracak. Bu özellik henüz geliştirme aşamasındadır. Ancak ekibin 3.0 sürümüyle sistemi kararlı hale getirmesini bekliyoruz.
• RAID-Z Expansion: Uzun zamandır beklenen özellik. Mevcut RAID-Z grubuna tek tek disk ekleyerek kapasite büyütmeyi mümkün kılacak. Kullanıcılar bu özelliği 2.3.3 sürümünden beri deneysel olarak Proxmox VE 9’da kullanabiliyor. Açıkçası ekibin 3.0 ile sistemi kararlı sürüme kavuşturmasını bekliyoruz.
• Fast Dedup: Geliştiriciler bu yenilemeyle klasik ZFS dedup sisteminin en büyük derdi olan RAM tüketimini çözmeyi amaçlıyor. Sonuç olarak sistemdeki yavaşlığı da ortadan kaldırıyorlar. 2.3 ile başlayan bu çalışma, 3.0 ile sistemin temel bir parçası olacak. Metadata yapısı baştan tasarlıyorlar.

ZFS Yedekleme & Replikasyon: zfs send ve receive Stratejileri

Snapshot ve Clone Kullanımı

Snapshot, bir datasetin anlık görüntüsünü alır. Neredeyse anında ve ek alan tüketmeden çalışır. zfs snapshot mypool/data@bugun komutu yeterlidir.

Bu anlık görüntüyü daha sonra klonlayabilirsiniz: zfs clone mypool/data@bugun mypool/data_clone. Klon, yazılabilir bir kopyadır ve sadece değişiklikler kadar yer kaplar.

Snapshot’ların otomatik alınması için sanoid veya zfs-auto-snapshot gibi araçlar kullanırım. Günlük, saatlik planlama yaparak veri kaybı penceresini minimize ederim.

Ayrıca raw send ile şifreli gönderim de yapabilirsiniz. Bu sayede yedekleme güvenliği artar. Snapshot ve clone kullanımı, yedekleme stratejinizin belkemiğidir. Kısacası depolama alanından tasarruf edersiniz.

Uzaktaki Sunucuya ZFS Replikasyonu (zfs send/receive)

ZFS replikasyon, snapshot’lar arası farkı sıkıştırılmış stream olarak gönderir. zfs send mypool/data@snap1 | ssh hedef zfs receive otherpool/data komutuyla uzak sunucuya kopyalarsınız.

İlk gönderim tam boyutlu olur, sonrakiler sadece değişiklikleri gönderir (incremental). Bu, bant genişliğinden tasarruf sağlar.

1. İlk senkronizasyon: zfs send mypool/data@snap1 | ssh hedef zfs receive -F otherpool/data
2. Sonraki artımlı gönderim: zfs send -i snap1 mypool/data@snap2 | ssh hedef zfs receive otherpool/data
3. Şifreli gönderim: zfs send -w mypool/secure@snap1 | ssh hedef zfs receive otherpool/secure

Felaket kurtarma senaryosunda, hedef havuzu import edip doğrudan kullanabilirsiniz. Bu yüzden off-site replikasyon, veri güvenliğinin temelidir.

Ben müşterilerimin tüm kritik verilerini her gece uzak lokasyona replike ederim. Böylece bir yangın veya doğal afet durumunda veri kaybı yaşanmaz. Replikasyon sırasında sıkıştırma kullanmak akıllıcadır. Diğer yandan zfs send -c ile sıkıştırma açarsanız ağ yükü azalır.

ZFS Güvenlik Özellikleri: Native Encryption ve ACL

Native Encryption (AES-256-GCM) ve LUKS Karşılaştırması

ZFS, veri şifreleme için AES-256-GCM kullanır. Native encryption, dataset seviyesinde çalışır ve anahtar yönetimi esnektir. Sistem bu süreçte verileri diske şifreli şekilde yazar.

Yetkisiz fiziksel erişime karşı tam koruma sağlar. LUKS disk şifreleme ile karşılaştırıldığında, ZFS şifreleme daha entegre ve performanslıdır. LUKS tüm diski şifrelerken, ZFS sadece belirli datasetleri şifreleyebilir.

ZFS native şifreleme, raw send ile şifreli replikasyon yapabilmenizi sağlar. LUKS’ta önce şifreyi çözmeniz gerekir. Bu da güvenlik riski oluşturur.

Ayrıca ZFS şifreleme, yerleşik anahtar değiştirme (key rotation) desteği sunar. Ben hassas veri içeren tüm datasetlerde native encryption açarım: zfs create -o encryption=on -o keyformat=passphrase mypool/secure.

ACL (Access Control Lists) ile Yetkilendirme

ZFS, NFSv4 ACL’leri doğal olarak destekler. Bu, klasik UNIX izinlerinden çok daha granüler yetkilendirme sağlar. Örneğin, bir dosyaya belirli kullanıcı için sadece okuma, diğerine yazma izni verebilirsiniz. Windows tarzı ACL’lerle entegre çalışır. Samba paylaşımlarında bu özellik sayesinde Windows istemciler sorunsuz yetkilendirme alır.

Dosya sistemi güvenlik duvarı ve ACL politikaları, çok kullanıcılı ortamlarda hayat kurtarır. Ben özellikle departman paylaşımlarında ACL kullanarak kullanıcıların sadece kendi klasörlerine erişmesini sağlarım. Bunu zfs set acltype=posixacl mypool/share ile etkinleştiririm.

Ayrıca ACL mirası (inheritance) sayesinde alt klasörlere otomatik yayılır. ACL yönetimi için getfacl ve setfacl komutları kullanılır. ZFS’in ACL desteği, FreeBSD ve Linux’ta sorunsuz çalışır.

ZFS Lisanslama ve Oracle / OpenZFS Ayrımı

CDDL ve GPL Uyumsuzluğu: Neden Linux Çekirdeğinde Yer Almıyor?

Sun şirketi, ZFS dosya sistemini CDDL lisansı ile piyasaya sürdü. CDDL, GPL ile uyumsuzdur. Bu sebeple geliştiriciler ZFS sistemini doğrudan Linux çekirdeğine ekleyemez.

Bunun yerine DKMS modülü olarak dışarıdan derlenir. Ubuntu gibi dağıtımlar, yasal gri alanda kalarak ikili modül dağıtır. Bu durum, çekirdek güncellemelerinde DKMS modülü sorunları yaşanmasına yol açar.

Ben birçok kez kernel güncellemesi sonrası ZFS modülünün derlenemediğini gördüm. Özellikle özel çekirdek kullanan sistemlerde bu can sıkıcıdır.

Çözüm, çekirdek sürümünü sabitlemek veya DKMS derleme bağımlılıklarını eksiksiz kurmaktır. Ama en temizi, ZFS destekli bir dağıtım (Ubuntu, Proxmox) kullanmaktır. Açık kaynak topluluk desteği ve gelişim süreci bu engelleri aşmaya devam ediyor.

Oracle ZFS vs OpenZFS: Güncel Farklar

Oracle ZFS, kapalı kaynak ve yalnızca Oracle Solaris ile gelir. Ek özellikler (çoklu protokol, şifreleme hızlandırma) içerir ancak topluluktan kopuktur.

OpenZFS ise açık kaynaklıdır ve FreeBSD, Linux, macOS üzerinde çalışır. Artık geliştirme liderliği tamamen OpenZFS projesi ndedir. Dolayısıyla Oracle sürümü giderek geride kalmaktadır.

OpenZFS 2.2 ile gelen block cloning ve Direct I/O gibi yenilikler Oracle ZFS’te yok. Ayrıca topluluk, daha hızlı hata düzeltme ve yeni özellikler sunar.

Kurumsal kullanımda artık OpenZFS tercih ediyorlar. Ben tüm yeni sistemlerde sadece OpenZFS kullanıyorum. Oracle bağımlılığı risklidir. Özetle ZFS’in geleceği OpenZFS’tedir.

ZFS Benchmark & Gerçek Performans Testleri

Farklı RAID-Z Yapılandırmalarında Performans (raidz1, raidz2, raidz3)

RAID-Z, geleneksel RAID5/6’nın yazılımsal ve daha güvenli versiyonudur. Write hole sorununu değişken şerit boyutu ile çözer. Raidz1, 1 disk toleranslıdır; raidz2, 2 disk; raidz3, 3 disk. Performans, kullanılan disk sayısına göre değişir.

Kendi testlerimde 8 diskli raidz2 kullandım. Sonuçta bunun 8 diskli raidz1’e göre daha düşük yazma IOPS’i verdiğini ölçtüm. Çünkü ek parite hesaplaması gerekir.

Aynı şekilde, resilvering süresi disk sayısı arttıkça uzar. Bu yüzden büyük havuzlarda mirror tercih ederim. Mirror, daha yüksek IOPS sunar, ancak alan verimliliği düşüktür. Kapasite odaklıysanız raidz2, performans odaklıysanız mirror.

Sıkıştırma Algoritmalarının Performansa Etkisi (LZ4 vs ZSTD vs GZIP)

LZ4, sıkıştırma sırasında neredeyse hiç CPU kullanmaz, IOPS’u düşürmez. Bu nedenle performans kritik ortamlarda idealdir. ZSTD, daha iyi sıkıştırma oranı sunar ama CPU tüketimi artar.

ZSTD seviye 1, 4 çekirdekli bir sunucuda LZ4’e kıyasla daha az IOPS üretti. Ancak bu senaryoda daha az alan kullandı. GZIP ise en yavaşıdır, sadece arşiv için uygundur.

Benim tavsiyem: Veritabanı logları, VM imajları gibi sık erişilen verilerde LZ4, arşiv ve yedeklerde ZSTD kullanın. Hangi algoritma daha iyi sorusunun cevabı iş yüküne bağlı.

ARC Boyutunun ve L2ARC’ın Okuma Performansına Etkisi

ARC, tekrarlı okumaları RAM’den sunarak gecikmeyi milisaniyelere düşürür. 64 GB RAM’li bir sunucuda, 50 GB ARC ile %95 isabet oranına ulaşabilirsiniz. Bu, veritabanı sorgularını 10 kat hızlandırır.

L2ARC ise, RAM’den düşen ama hala sık okunan veriyi NVMe’de saklar. ARC isabet oranını %99’a çıkarabilir, ama çok fazla RAM tüketimi pahasına.

L2ARC eklemeden önce ARC boyutunu maksimuma çıkarın. Testlerimde, L2ARC eklemek, rastgele okuma performansını %15 artırdı. Ancak sürekli yazma yükü altında L2ARC besleme gecikmesi oluştu. Bu yüzden sadece okuma ağırlıklı iş yüklerinde L2ARC öneririm.

ZFS ile İlgili Yaygın Efsaneler & Yanlış Anlamalar

Efsane 1: “ZFS Çok Fazla RAM Yer, Bu Yüzden Küçük Sistemler İçin Değil”

Bu efsane, ARC’nin varsayılan olarak belleğin yarısını kullanmasından kaynaklanır. Ancak ARC, ihtiyaç duyulduğunda belleği uygulamalara bırakır. 4 GB RAM’li bir sistemde bile ZFS sorunsuz çalışır.

Ben bir Raspberry Pi 4’te (4 GB RAM) dahi ZFS kullandım, dosya sunucusu olarak yetti. ARC boyutunu sınırlandırabilirsiniz. Yani küçük sistemler için de uygundur.

Asıl sorun, dedup açıldığında RAM kullanımının patlamasıdır. Ama dedup opsiyoneldir. Sistemi salt dosya sistemi olarak kullanırsanız, ext4’ten biraz fazla RAM harcarsınız. Ne var ki bu durumu çoğu senaryoda fark etmezsiniz. Ayrıca RAM maliyeti ucuzladı, 8 GB bile yeterlidir. Dolayısıyla bu efsane çürümüştür.

Efsane 2: “ZFS için ECC RAM Zorunludur”

ECC RAM, bellek hatalarını düzeltir. ZFS, veri bütünlüğünü diske yazarken checksum yapar, ancak bellekteki bozulmayı göremez.

ECC RAM olmadan da ZFS çalışır, ancak teorik bir risk vardır. Aslında insanlar, milyonlarca non-ECC sistemde ZFS’i sorunsuz şekilde çalıştırıyor.

Ben ev sunucularımın çoğunda ECC kullanmadım, hiç veri kaybı yaşamadım.ECC zorunlu değildir, ama öneririm. Kısacası bütçeniz varsa alın, yoksa korkmayın.

Efsane 3: “ZFS, EXT4’ten Çok Daha Yavaştır”

Kullanıcılar bu karşılaştırmayı genelde ham IOPS üzerinden yapar. Evet, ZFS checksum ve CoW nedeniyle ek yük getirir. Ama ARC sayesinde okumada çok daha hızlıdır. Ayrıca sıkıştırma, yazma amplifikasyonunu azaltarak SSD’lerde yazma hızını artırabilir.

Testlerimde, PostgreSQL üzerinde ZFS (recordsize=8K, LZ4) EXT4’e göre %25 daha fazla sorgu/sn verdi. Çünkü ARC, sorgu tekrarlarını yakaladı. Yani gerçek hayatta ZFS genellikle daha hızlıdır.

ZFS Yönetim Araçları & İzleme (zpool iostat, zfs list, Grafana)

Temel İzleme Komutları: zpool iostat, zfs list, zpool status

Havuz sağlığını anlık izlemek için birkaç komut yeterli. zpool status -v size havuzdaki tüm diskleri, hataları ve scrub durumunu gösterir. Ben bunu cron ile saat başı kaydederim. zpool iostat 1 saniyelik IO istatistikleri verir; darboğaz anında ilk baktığım yerdir. zfs list -o space ise datasetlerin alan kullanımını gösterir.

• zpool status -v: Havuz sağlığı ve disk durumu
• zpool iostat 1: Gerçek zamanlı IOPS ve bant genişliği
• zfs list -o space: Dataset alan kullanımı
• arc_summary: ARC isabet oranı ve RAM detayı

Ayrıca arc_summary ile ARC isabet oranını, bellek kullanımını detaylıca görürüm. Performans sorunlarında ARC yetersiz mi, L2ARC gerekli mi hemen analrım.

Grafana + Prometheus ile ZFS Metriklerini Görselleştirme

Uzun süreli trend analizi için Prometheus ve Grafana kullanıyorum. node_exporter ve zfs_exporter ile tüm metrikleri toplarım. Havuz doluluğu, IO gecikmesi, ARC isabet oranı gibi panolar oluştururum.

Özellikle kapasite planlaması ve performans sorunlarını önceden tahmin etmede bu görselleştirme hayat kurtarır. OpenZFS topluluğu, Grafana şablonları bile sunar; kurumsal ortamda şarttır.

Kurulumu basit: docker-compose ile Prometheus+Grafana ayağa kaldırır, zfs_exporter’ı sunucuya kurup metrikleri hedef olarak eklersiniz.

ZFS Dosya Sistemi İçin İleri Okuma Kaynakları

Bu rehberi sahadan edindiğimiz deneyimlerle hazırladık. Ancak ZFS’in derinliklerine inmek isterseniz, aşağıdaki kaynakları mutlaka inceleyin. Çünkü sektör, bu kaynakların her birini depolama mimarisi konusunda otorite kabul eder.

1. OpenZFS Resmi Dokümantasyonu – Bu kaynak, bu storage pool’un en güncel ve kapsamlı teknik dökümanlarını sunar. Özellikle “Performance and Tuning” ve “Module Parameters” bölümlerini incelemelisiniz. Açıkçası bu bölümler, dosya sistemini derinlemesine anlamak ve optimize etmek isteyen uzmanlara hitap ediyor.
2. 45Drives: Tek Sunucu Yedeklemeleri için En İyi Uygulama Mimarisi – 45Drives mühendisleri, bu kapsamlı rehberde ZFS havuz yapılandırması, anlık görüntü stratejileri ve donanım seçimi konularında saha deneyimlerini paylaşıyor. Özellikle büyük ölçekli yedekleme sunucuları için bu pratik öneriler hayat kurtarıcıdır.
3. OpenZFS 2.3 Sürüm Notları (Phoronix) – Bu kaynakta OpenZFS 2.3 ile gelen devrim niteliğindeki özellikleri detaylıca inceleyebilirsiniz. Örneğin RAIDZ Expansion, Fast Dedup ve Direct I/O bunlardan bazılarıdır. Üstelik bu döküman, dosya sisteminin geleceğine dair en güncel bilgileri önünüze seriyor. Özellikle NVMe SSD’lerde ARC bypass ile elde edilen performans kazanımları dikkat çekicidir.
4. Netgate Performans Ayar Rehberi – Bu rehber, ZFS ARC bellek yönetiminden başlayarak bu storage pool’un farklı iş yüklerinde nasıl yapılandırılacağını adım adım anlatır. Özellikle “Free RAM is wasted RAM” felsefesini öğrenmek istiyorsanız bu rehber tam size göredir. Bununla birlikte rehber sayesinde ARC’nin nasıl çalıştığını ve sistem RAM’ini nasıl yönettiğini kolayca anlarsınız.
5. Ubuntu Dokümantasyonu – Ubuntu’nun resmi dokümantasyonu, bu storage pool’un temel kavramlarını (zpool, dataset, snapshot, clone) ve LXD ile entegrasyonunu detaylıca açıklar. Özellikle container ortamlarında ZFS kullanımı ve autotrim yapılandırması konularında pratik bilgiler içerir.
6. FreeBSD Handbook– FreeBSD, bu yazılım tanımlı depolama çözümünü doğal olarak destekleyen en olgun platformlardan biridir. Bu kılavuz, root-on-ZFS kurulumundan jail entegrasyonuna kadar tüm pratik uygulamaları adım adım açıklar. Bunun yanı sıra anlık görüntü yönetiminden boot environment’lara kadar her detayı burada bulursunuz.

ZFS Hakkında Kafanıza Takılan Her Şey: 10 SSS

Sonuç: ZFS Karar Matrisi — Sizin İçin Doğru Seçim mi?

Veri bütünlüğü sizin için öncelikliyse, ZFS tartışmasız doğru seçimdir. Özellikle NAS, sanallaştırma, veritabanı ve yedekleme ortamlarında rakipsizdir.

Yerleşik snapshot, sıkıştırma, şifreleme ve ACL ile tam bir depolama platformudur. OpenZFS 2.4 ile gelen Block Cloning, Direct I/O, RAID-Z Expansion ve Fast Dedup gibi yenilikleri görürüz.

Geliştiricilerin 3.0 sürümünde olgunlaştıracağı bu özellikler sayesinde esneklik ve performans katlanarak artar. Eğer veri kaybı kabul edilemez diyorsanız, ZFS kurun.

Ancak bazı durumlarda ZFS fazla gelebilir. Örneğin, tek diskli bir web sunucusunda, sadece statik dosya barındıracaksanız, ext4 yeterlidir. ZFS’in öğrenme eğrisi ve RAM kullanımı burada gereksiz karmaşa yaratabilir.

Yüksek frekanslı ticaret gibi sürekli yazma yapan yüksek IOPS’lu uygulamaları düşünebiliriz. Şöyle ki, bu sistemlerde ZFS’in CoW yapısı gecikmelere yol açabilir. O zaman XFS veya ext4 daha uygun olur.