SSD Nodes Learn Hosting plans →
Rehberler Matt ConnorYazan Matt Connor · Güncellendi 2026-08-27

ZFS RAM kullanımı ve VPS üzerinde performans yönetimi

ZFS, ARC ile sistem belleğinin büyük bir kısmını talep eder. 2 GB veya 4 GB RAM kapasiteli VPS sunucularda performans kaybı yaşamadan ZFS yapılandırması nasıl yapılır?

ZFS'in sundukları ve gerektirdikleri

FreeBSD ve Linux üzerindeki ZFS artık tek bir kod tabanı olan OpenZFS'tir, bu nedenle özellikler her iki sistemde de aynıdır. ZFS çalıştıran bir sunucu; sağlama toplamı (checksum) ile doğrulanmış veriler, veri değişene kadar maliyeti olmayan snapshot'lar, zfs send ile replikasyon ve tek bir özellik ayarıyla aktifleşen sıkıştırma avantajlarına sahip olur. ZFS'in gerektirdiği ise bellektir: ARC (adaptive replacement cache), varsayılan olarak RAM'in büyük bir kısmını talep eder; 2 GB veya 4 GB'lık bir VPS (virtual private server) üzerinde bu bellek, tam olarak uygulamanızın ihtiyaç duyduğu alandır.

Bu rehber, ZFS'i kırk sürücü yuvasına sahip bir depolama sunucusu üzerinden değil, bir veya iki sanal diske sahip kiralanmış bir VPS üzerinden değerlendirmektedir. Bu geçişten sağ çıkan özellikler, zaman ayırmaya değer olanlardır. Sağ çıkamayan kısımlar ise bir havuz oluşturmadan önce bilinmesi gerekenlerdir.

FreeBSD ve Linux üzerinde OpenZFS: tek kod tabanı, iki paketleme hikayesi

FreeBSD, 2008 yılındaki FreeBSD 7.0 sürümünden bu yana ZFS'i, başlangıçta deneysel bir özellik olarak temel sisteminde barındırmaktadır. Aralık 2020'deki OpenZFS 2.0 sürümünden itibaren FreeBSD ve Linux aynı kaynak ağacından derlenmektedir; bu nedenle zfs ve zpool her iki platformda da aynı şekilde çalışır ve birinde oluşturulan bir havuz diğerine aktarılabilir.

ZFS'in Linux'ta bir paket, FreeBSD'de ise temel sistemin bir parçası olmasının nedeni lisanslamadır. OpenZFS, CDDL (common development and distribution license) altındadır. Linux çekirdeği ise GPL (general public license) sürüm 2 altındadır. Çekirdek projesi bu iki lisansı uyumsuz kabul ettiğinden, ZFS kodu ana Linux hattına dahil edilmemiştir ve her dağıtım bunu nasıl sunacağına kendisi karar verir. FreeBSD'de böyle bir çelişki yoktur, bu yüzden ZFS doğrudan sistemde yer alır. Pratik hikayenin tamamı budur: tek bir paketleme farkı vardır ve taraf tutmanızı gerektirecek bir durum söz konusu değildir.

SSD Nodes FreeBSD imajları sunmadığından, buradan kiralanan bir sunucuda bu kılavuzun Linux ile ilgili kısmı geçerlidir. Başka bir yerde FreeBSD çalıştırıyorsanız, bir FreeBSD sunucusu üzerinde ZFS, derlenecek bir modül veya hayatta kalınması gereken bir çekirdek yükseltmesi olmadan doğrudan gelir.

ZFS kurulumu ve havuz oluşturma

Ubuntu üzerinde modül çekirdek paketlerinin içinde gelir, bu nedenle yalnızca komutları kurmanız yeterlidir.

sudo apt update
sudo apt install -y zfsutils-linux
zfs version

zfs version komutu, kullanıcı alanı sürümü ve çekirdek modülü sürümü olmak üzere iki satır çıktı verir. Tek satır çıktı alınması, modülün yüklenemediği anlamına gelir. Paket universe bileşeninde yer alır ve Ubuntu sunucu imajlarında varsayılan olarak etkindir; eğer apt paketi bulamazsa önce sudo add-apt-repository universe komutunu çalıştırın.

Debian üzerinde paketler contrib bileşeninde bulunur ve modül, DKMS (dinamik çekirdek modülü desteği) aracılığıyla makinenizde derlenir. contrib ifadesini /etc/apt/sources.list.d/debian.sources içindeki Components: satırına ekleyin, sudo apt update komutunu çalıştırın ve ardından şunları uygulayın:

sudo apt install -y linux-headers-$(dpkg --print-architecture) zfs-dkms zfsutils-linux

Kurulum işlemi modülü derler ve birkaç dakika süren Building initial module for 6.12.0-... çıktısını verir. Bunun ne anlama geldiğini unutmayın: her çekirdek yükseltmesinde modül yeniden derlenir; başarısız bir derleme, siz sorunu giderene kadar havuzunuzun içe aktarılamamasına neden olur.

FreeBSD üzerinde herhangi bir kurulum gerekmez. Servisi etkinleştirin ve başlatın.

sysrc zfs_enable=YES
service zfs start

Şimdi havuzu oluşturalım. Öncelikle kararlı aygıt yollarına bakın, çünkü /dev/vdb algılama sırasına göre atanır ve başka bir birim bağladığınızda değişebilir.

ls -l /dev/disk/by-id/
sudo zpool create -o ashift=12 tank /dev/disk/by-id/virtio-abc123def456
zpool status tank

zpool status komutu, aygıtınızın tank altında listelendiği state: ONLINE çıktısını vermelidir. ashift=12 parametresi, havuzun en küçük bloğunu 4 KiB olarak sabitler; bu değer güncel SSD'lerle uyumludur ve oluşturulduktan sonra değiştirilemez.

Kiralanan çoğu imaj ext4 kök dizininden başlatılır, bu nedenle buradaki ZFS, kök dosya sistemi yerine ikinci bir birim üzerindeki veri havuzudur. Üzerinde işlem yapmadan önce aygıtın doğru olduğundan emin olun; çünkü size satılan NVMe diski doğrulamak bir dakika sürerken, yeniden kurulum yapmak bir öğleden sonranızı alabilir.

Sağlama toplamları yalnızca havuz yedekliliğe sahipse onarım yapabilir

ZFS tarafından yazılan her blok bir sağlama toplamı (checksum) taşır ve her okuma işlemi bunu doğrular. Algılama her zaman çalışır. Onarım ise ikinci bir kopya gerektirir.

Tek diskli bir havuzda ZFS size gerçeği söyler ve orada durur. zpool status -v bunu şu şekilde raporlar:

status: One or more devices has experienced an error resulting in data
        corruption.
action: Restore the file in question if possible.  Otherwise restore the
        entire pool from backup.
errors: Permanent errors have been detected in the following files:

        /tank/data/archive.tar

Hatalı dosya belirtilir. ext4 bu baytları yorumsuz bir şekilde döndürürdü, bu nedenle bu durum halihazırda bir değer ifade eder. ZFS yine de bunu düzeltemez, çünkü havuzda onarım için kullanılabilecek ikinci bir kopya yoktur.

Bir yansıtma (mirror) yapısında aynı okuma işlemi sağlam taraftan karşılanır, hatalı blok yeniden yazılır ve olay zpool status komutunun CKSUM sütununda görünür. Bu, kendi kendini iyileştirmedir ve iki cihaz gerektirir.

sudo zpool create -o ashift=12 tank mirror /dev/disk/by-id/DISK1 /dev/disk/by-id/DISK2

Bir VPS üzerinde ana bilgisayar depolaması genellikle zaten yedeklidir, bu durum sıklıkla hipervizör altında RAID 10 yapısıdır. Bu sizi ölü bir sürücüye karşı korur. Ancak bir blok hatalı döndüğünde size bunu bildirmez, çünkü dizinin hangi kopyanın doğru olduğunu bilme şansı yoktur. ZFS bunu bilir, çünkü veriyi bizzat kendisinin yazdığı bir sağlama toplamı ile karşılaştırır.

Eğer tek bir sanal diskiniz varsa ve bir miktar onarım yeteneği istiyorsanız, sudo zfs set copies=2 tank/important o veri kümesinin (dataset) her bloğunun iki kopyasını aynı disk üzerinde saklar. Bu, veri kümesinin kullandığı alanı iki katına çıkarır, hatalı bir bloğa karşı koruma sağlar ancak tüm birim kaybolduğunda hiçbir işe yaramaz.

Bir scrub işlemi, havuzdaki her şeyi okur ve doğrular.

sudo zpool scrub tank
zpool status tank

Sağlıklı bir havuz, scan: scrub repaired 0B in 00:04:11 with 0 errors gibi bir satırla sona erer. Bunu bir zamanlamaya bağlayın; küçük bir havuz için aylık periyot yeterlidir.

systemctl list-unit-files 'zfs-scrub*'
sudo systemctl enable --now zfs-scrub-monthly@tank.timer

Veri kümeleri (dataset) ilke birimidir

Veri kümesi, havuz (pool) içindeki bir dosya sistemidir ve oluşturulması maliyetsizdir; bu nedenle her iş için bir tane oluşturun. Özellikler havuzdan aşağıya doğru miras alınır; bu da varsayılan bir ayarı bir kez yapıp, gerektiğinde geçersiz kılabileceğiniz anlamına gelir. FreeBSD üzerinde jail yapıları genellikle bu şekilde çalıştırılır; her jail için bir veri kümesi kullanılır. Böylece tek bir jail kendi başına snapshot alınabilir ve geri döndürülebilir; bu durum bir jail'i Docker container'ından ayıran özelliklerden biridir.

sudo zfs create tank/data
sudo zfs create tank/pg
sudo zfs set compression=lz4 tank
sudo zfs set atime=off tank
sudo zfs set quota=20G tank/data
sudo zfs set recordsize=16K tank/pg
zfs get -r compression,compressratio,quota tank

Sıkıştırma, insanların temkinli davranarak kullanmadığı ancak aslında tam tersi bir etkiye sahip olan bir özelliktir. lz4 az miktarda CPU tüketir ve diske ulaşması gereken bayt miktarını azaltır; bu nedenle sıkıştırılabilir verilerde okuma ve yazma işlemlerini genellikle hızlandırır. zstd daha fazla CPU kullanarak daha güçlü sıkıştırma yapar; bu, nadiren okuduğunuz günlükler ve arşivler için uygundur. zfs get compressratio tank ile gerçekte ne elde ettiğinizi kontrol edin ve oran değerinin yalnızca özellik ayarlandıktan sonra yazılan verileri kapsadığını unutmayın.

recordsize, bir veri kümesinin yazdığı en büyük blok boyutudur ve varsayılan olarak 128K'dır. 128 KiB'lık kayıtlara 8 KiB'lık sayfalar yazan bir veritabanı, küçük bir yazma işlemini tüm kaydın okunmasına, değiştirilmesine ve geri yazılmasına dönüştürür. Verileri yüklemeden önce veritabanı veri kümesi üzerinde recordsize=16K ayarını yapın, çünkü bu özellik yalnızca yeni yazılan bloklar için geçerlidir.

quota, bir veri kümesinin havuzu tamamen doldurmasını engellemenin yoludur. %100 doluluğa yaklaşan bir ZFS havuzu yavaşlar ve temizlenmesi zorlaşır; bu nedenle kasıtlı olarak boş alan bırakın.

Snapshot'lar veri değişene kadar yer kaplamaz

ZFS, canlı bir bloğun üzerine asla yazmaz. Copy-on-write (yazma anında kopyalama) prensibi gereği, yeni bir blok yazar ve işaretçileri günceller. Snapshot, "bu veri kümesinin şu an işaret ettiği blokları tut" diyen bir nottur; bu nedenle oluşturulması anlık ve ücretsizdir.

sudo zfs snapshot tank/data@2026-08-11
zfs list -t snapshot -o name,used,refer -r tank/data

Bir snapshot için USED sütunu, yalnızca o snapshot tarafından tutulan alanı gösterir. Veri değiştirdiğinizde veya sildiğinizde eski bloklar serbest bırakılamayacağı için bu değer sıfıra yakın başlar ve zamanla artar.

Bir dosyayı geri almak için geri yükleme (restore) adımı gerekmez.

ls /tank/data/.zfs/snapshot/
cp /tank/data/.zfs/snapshot/2026-08-11/notes.txt /tank/data/notes.txt

.zfs dizini, sudo zfs set snapdir=visible tank/data komutunu çalıştırana kadar ls -a için bile gizlidir. Snapshot'ı ihtiyaç duymadan önce alın; çünkü snapshot olmadan yapılacak hatalı bir rm -rf, sizi ext4 kurtarma yolu ile baş başa bırakır ki bu süreç diski unmount etmekle başlar ve daha da zorlaşır.

Geri alma (rollback) işlemi, snapshot'tan sonra yazılan her şeyi siler.

sudo zfs rollback tank/data@2026-08-11

Daha yeni snapshot'lar mevcutsa işlem reddedilir; -r komutu devam etmek için bu yeni snapshot'ları yok eder. Enter tuşuna basmadan önce veri kümesi adını iki kez kontrol edin.

Snapshot bir yedekleme değildir. Aynı havuzda, aynı birimde ve aynı sunucuda bulunur. Arızalı bir birim veya zpool destroy durumu, snapshot'ları verilerle birlikte yok eder. Snapshot'lar sizi kendi rm hatalarınızdan ve hatalı yükseltmelerden korur; bu da gerçek vakaların büyük bir kısmını kapsar. Ancak havuzun kendisine zarar veren durumlara karşı koruma sağlamaz. Konunun tamamı burada açıklanmıştır: neden bir VPS snapshot'ı yedekleme değildir.

Gönderme ve alma: tek komutla replikasyon

zfs send, bir snapshot'ı standart çıktı üzerinde bayt akışına dönüştürür; zfs receive ise bu akışı tekrar bir veri kümesine (dataset) çevirir. İlk kopyalama işlemi tam bir gönderimdir.

sudo zfs snapshot tank/data@daily-2026-08-11
sudo zfs send tank/data@daily-2026-08-11 | ssh backup.example.com "sudo zfs recv -F backup/data"

Bundan sonra, yalnızca iki snapshot arasında değişen verileri gönderin.

sudo zfs snapshot tank/data@daily-2026-08-12
sudo zfs send -i tank/data@daily-2026-08-11 tank/data@daily-2026-08-12 | ssh backup.example.com "sudo zfs recv backup/data"

Alıcı taraf, gönderim yaptığınız snapshot'ı hâlâ tutuyor olmalıdır. Bu snapshot mevcut olmadığında, ZFS farkı uygulayacak bir temel bulamadığı için alım işlemi cannot receive incremental stream: most recent snapshot of backup/data does not match incremental source hatasıyla durur. Her iki tarafın da sahip olduğu bir snapshot üzerinden gönderim yapın veya tam bir gönderimle yeniden başlayın.

Uzak sunucuda root yetkisi kullanmak yerine hedef tarafta hak tanımlayın: sudo zfs allow -u backupuser create,mount,receive backup/data.

Bu, tek bir koşulla gerçek bir saha dışı (off-site) yedekleme yöntemidir. Nesne depolama birimleri bir akışı doğrudan alamayacağı için, uzak uç bir ZFS havuzu olmalıdır. Hedefiniz S3 uyumlu bir depolama alanı veya standart bir Linux sunucusu ise, bu tür sistemlerle iletişim kurabilen bir araç kullanın; VPS üzerinden restic yedekleri bu yöntemi kapsamaktadır.

ZFS neden bu kadar çok RAM kullanıyor? ARC

ARC (adaptive replacement cache), ZFS'nin okuma önbelleğidir. Normal Linux sayfa önbelleği yerine çekirdek belleğinde yer alır, bu nedenle free -h bunu buff/cache altında raporlamaz. Kullanımdaki bellek olarak görünür. Neredeyse dolu görünen bir ZFS sunucusu genellikle önbelleği dolu olan bir sunucudur ve "ZFS RAM'imi tüketti" raporlarının çoğu bu durumdan kaynaklanır.

Varsayılan sınır kasıtlı olarak cömert tutulmuştur. OpenZFS 2.3, maksimum ARC boyutunu RAM eksi 1 GiB ile RAM'in 5/8'i değerlerinden büyük olanı baz alacak şekilde ayarlar. OpenZFS 2.2 ve önceki sürümler Linux üzerinde RAM'in yarısını kullanırken, FreeBSD zaten yeni kuralı uygulamaktaydı. Sizin sisteminizde hangisinin geçerli olduğunu görmek için zfs version komutunu çalıştırın.

ChartDefault maximum ARC size by instance RAM, from the OpenZFS default rule (GiB)
The data behind this chart
[
  {
    "label": "2 GB VPS",
    "openzfs_2_2_linux_gib": 1,
    "openzfs_2_3_gib": 1.25
  },
  {
    "label": "4 GB VPS",
    "openzfs_2_2_linux_gib": 2,
    "openzfs_2_3_gib": 3
  },
  {
    "label": "8 GB VPS",
    "openzfs_2_2_linux_gib": 4,
    "openzfs_2_3_gib": 7
  },
  {
    "label": "16 GB VPS",
    "openzfs_2_2_linux_gib": 8,
    "openzfs_2_3_gib": 15
  }
]

Bu rakamlar, çalışan bir sunucudan alınan ölçümler değil, yaygın sunucu boyutları için belgelenmiş varsayılan kuraldır. 4 GB'lık bir sunucuda 2.3 kuralı, 3 GiB boyutunda bir ARC'ye izin verir. Aynı sunucu 2.2 sürümünde 2 GiB değerinde durur. 2.3 kuralı altındaki 2 GB'lık bir sunucu ise hala 1.25 GiB değerine izin verir. Uygulamanız ise geriye kalan belleği kullanır.

Tabloya güvenmek yerine gerçek rakamları kendi sunucunuzdan okuyun:

grep -E '^(size|c_max) ' /proc/spl/kstat/zfs/arcstats
arc_summary | head -n 20

Üçüncü sütun bayt cinsindendir. c_max şu anda geçerli olan üst sınırdır, size ise ARC'nin halihazırda tuttuğu miktardır.

ARC belleği geri verir. Çekirdek bellek baskısı sinyali gönderdiğinde ARC küçülür. Sorun zamanlamadır; çünkü küçülme süreci bu baskı tarafından tetiklenir. Bu nedenle, bir anda birkaç yüz MiB talep eden bir işlem, ARC henüz serbest bırakma yaparken OOM (out of memory) killer ile karşılaşabilir. Veritabanı ve web sunucusu çalıştıran 2 GB'lık bir sunucuda bu nadir bir durum değildir. OpenZFS kılavuzu, manuel değişiklikler hakkında da aynı şeyi belirtir: sınırı düşürmek, "küçülmeyi tetikleyecek bir bellek baskısı olmadan ARC'nin küçülmesine neden olmaz".

Küçük bir VPS üzerinde ARC sınırlandırması nasıl yapılır

Öncelikle iş yükünün bellek ihtiyacını belirleyin. Veritabanı ve uygulamanın ihtiyaçlarını toplayın, işletim sistemi için bir pay bırakın ve geri kalanını ARC'ye ayırın. Postgres ve bir web uygulaması çalıştıran 4 GB'lık bir örnekte, 512 MiB ile 1 GiB arası ARC makul bir başlangıç noktasıdır.

Bunu bayt cinsinden canlı olarak ayarlayın. Bu örnek 1 GiB içindir.

echo 1073741824 | sudo tee /sys/module/zfs/parameters/zfs_arc_max

Yeniden başlatma sonrasında kalıcı olmasını sağlayın.

echo 'options zfs zfs_arc_max=1073741824' | sudo tee /etc/modprobe.d/zfs.conf
sudo update-initramfs -u

initramfs adımı önemlidir; çünkü modül, kök dosya sistemi bağlanmadan önce initramfs üzerinden yüklenebilir, bu da az önce oluşturduğunuz dosyayı asla okumayacağı anlamına gelir. Yeniden başlatmanın ardından, arcstats içindeki c_max satırı ile doğrulamayı yapın.

Kılavuzun kendisinden gelen iki uyarı bulunmaktadır. Sistem çalışırken değeri tekrar 0 yapamazsınız; bu nedenle değişikliği geri almak için dosyayı düzenleyip sistemi yeniden başlatmanız gerekir. Ayrıca sayıyı düşürmek, halihazırda büyük olan bir ARC'yi anında küçültmez.

FreeBSD üzerinde aynı sınır vfs.zfs.arc altında bir sysctl değeridir. Mevcut değerleri ve sürümünüzün kullandığı tam ismi görmek için sysctl vfs.zfs.arc komutunu çalıştırın, ardından maksimum değeri /boot/loader.conf içine yazın.

Küçük bir sunucu için iki bellek kuralı daha vardır. Deduplication (tekilleştirme) özelliğini kapalı tutun; çünkü dedup tablosu bellekte tutulur ve genel kabul gören kural, her 1 TB benzersiz veri için 1 ila 3 GB RAM gerektiği yönündedir. Ayrıca swap alanını bir zvol (havuzdan ayrılmış bir blok aygıtı) üzerine koymayın; çünkü belleği boşaltmaya çalışan dosya sistemi üzerinden swap yapmak makinenin kilitlenmesine (deadlock) neden olabilir. Swap alanını havuzun dışında, düz bir bölüm (partition) veya swap dosyası üzerinde tutun.

ext4 veya XFS ile restic ikilisinin daha iyi bir çözüm olduğu durumlar

ZFS, boşta belleği ve ikinci bir diski olan sunucularda değerini kanıtlar. Bunun dışındaki durumlarda, standart bir dosya sistemi ile gerçek bir yedekleme aracı kullanmak daha avantajlıdır. Aşağıdaki durumlarda ext4 veya XFS tercih edilmelidir:

  • Sunucu 2 GB veya 4 GB RAM'e sahipse ve iş yükü bu belleğin tamamına ihtiyaç duyuyorsa.
  • Tek bir sanal disk varsa ve ikinci bir kopya bulunmuyorsa; bu durumda ZFS, onarım imkanı olmaksızın yalnızca hata tespiti sağlar.
  • Yedekleme hedefi nesne depolama (object storage) veya standart bir Linux sunucusu ise; bu hedefler zfs send akışını kabul edemez.
  • DKMS ile Debian kullanıyorsanız ve modülün derlenmediği bir çekirdek yükseltmesini göze alamıyorsanız.
  • Kök dosya sisteminde ZFS kullanmanız gerekiyorsa ancak sağlayıcının sunduğu imajlar yalnızca ext4 destekliyorsa.

Ayrı bir veri diskiniz, boşta belleğiniz (8 GB ve üzeri rahat bir seviyedir) ve snapshot ile zfs send özelliklerini sadece etkinleştirmekle kalmayıp bunları kullanan bir planınız varsa ZFS kullanmaya devam edin. Diğer tüm senaryolarda, sunucunun kontrolü altında olmayan bir depolama alanına şifreli ve tekilleştirilmiş yedekler yazan restic ile ext4 ikilisi, bellek tüketimi yaratmadan benzer gereksinimlerin çoğunu karşılar.

Hata modları ve karşılaşacağınız dizgeler

Yeniden başlatma sonrasında havuz kayboluyor. zpool status komutu no pools available çıktısını verir. İçe aktarma servisi /etc/zfs/zpool.cache dosyasını okur; bu nedenle söz konusu dosyada bulunmayan bir havuz açılışta asla içe aktarılmaz. sudo zpool import içe aktarılabilir olanları listeler, sudo zpool import tank havuzu geri getirir ve sudo zpool set cachefile=/etc/zfs/zpool.cache tank bu işlemi kalıcı hale getirir. Başka bir sistemden düzgün bir şekilde dışa aktarılmamış bir havuz cannot import 'tank': pool may be in use from other system hatası verir; başka bir ana makinenin havuza erişmediğinden eminseniz sudo zpool import -f tank bu durumu geçersiz kılar.

Debian üzerinde çekirdek yükseltmesi sonrası modprobe: FATAL: Module zfs not found in directory /lib/modules/6.12.0-.... DKMS yeni çekirdek için derleme yapmamıştır; bunun nedeni genellikle eşleşen başlık dosyalarının (headers) yüklü olmamasıdır. dkms status hangi çekirdek için nelerin derlendiğini gösterir. sudo apt install -y linux-headers-$(uname -r) ve ardından sudo dkms autoinstall komutları derlemeyi yeniden yapar, sudo zpool import tank ise havuzu geri getirir.

Havuz dolu ancak dosyaları sildiniz. Silinen veriler, bir anlık görüntü (snapshot) onları referans almaya devam ettiği sürece diskte kalır; bu nedenle du ve df farklı değerler gösterir. zfs list -o space -r tank kullanımı USEDDS ve USEDSNAP olarak ayırır; yüksek bir USEDSNAP değeri sorunun kaynağıdır. Eski anlık görüntüleri sudo zfs destroy tank/data@2026-06-01 ile silerseniz alan geri kazanılır.

zpool status içinde CKSUM sayıları artıyor. ZFS'nin altındaki bir katman hatalı veri döndürüyor demektir. Bir yansıtılmış (mirror) havuzda bu sayı bir uyarıdır ve blok onarılmıştır. Tek diskli bir havuzda ise dosya kaybolmuştur; zpool status -v dosyanın adını verir ve bu dosyayı havuzun dışında bulunan bir yedekten geri yüklemeniz gerekir.

Sunucu yavaş ve takas (swap) kullanıyor. ARC boyutunu yukarıda belirtildiği gibi sınırlayın, ardından arc_summary komutunu çalıştırarak isabet oranını (hit ratio) inceleyin. Çalışma kümesini tutamayacak kadar küçük bir ARC, her okuma işleminin diske gitmesi demektir; bu noktada sayfa önbelleğini (page cache) kullanan standart bir dosya sistemi size daha iyi hizmet verecektir.

FAQ

Bir VPS üzerinde ZFS ne kadar RAM'e ihtiyaç duyar?

ZFS, 2 GB'lık bir örnek üzerinde çalışabilir. Asıl soru, uygulamanız için ne kadar RAM kaldığıdır. Herhangi bir ince ayar yapılmadığında, OpenZFS 2.3, ARC'nin RAM eksi 1 GiB ile RAM'in 5/8'i arasındaki büyük değere kadar büyümesine izin verir; bu nedenle 4 GB'lık bir sunucu, önbellek için 3 GiB ayırabilir. zfs_arc_max değerini iş yükünüzün ayırabileceği bir sayıya ayarlayın, ardından /proc/spl/kstat/zfs/arcstats içindeki c_max satırını okuyarak bunu doğrulayın.

ZFS snapshot bir yedekleme midir?

Hayır. Bir snapshot, verilerle aynı havuzda (pool) yaşar. Hatalı bir rm işleminden veya başarısız bir yükseltmeden sağ çıkabilir, ancak havuz veya sunucu örneği ile birlikte yok olur. Snapshot'ı, zfs send ile başka bir makineye göndererek veya bu sunucunun kontrol etmediği bir depolama alanına yazan bir yedekleme aracı çalıştırarak yedeklemeye dönüştürün.

ZFS, FreeBSD ve Linux üzerinde aynı şekilde mi çalışır?

Aralık 2020'deki OpenZFS 2.0 sürümünden beri aynı kod tabanına, aynı komutlara ve aynı disk içi formata sahiptir; havuzlar bu sistemler arasında taşınabilir. Fark paketlemededir. FreeBSD, ZFS'i temel sistemin bir parçası olarak sunar. Linux tarafında ise her dağıtım kendi kararını verir: Ubuntu modülü çekirdek paketlerine dahil ederken, Debian bunu DKMS ile makinenizde derler; bu nedenle bir çekirdek yükseltmesi, yeniden derleme başarılı olana kadar sizi modülsüz bırakabilir.

ZFS, tek diskli bir VPS üzerinde bozulmaları onarabilir mi?

Bozulmayı tespit eder ve ilgili dosyayı belirtir, ancak onaramaz; çünkü onarım işlemi bloğun ikinci bir kopyasını gerektirir. Bir veri kümesi (dataset) üzerinde zfs set copies=2 kullanmak, size iki kat alan maliyetiyle o ikinci kopyayı sağlar; bu, hatalı bir bloğu yönetebilir ancak kaybolan bir birimi kurtaramaz. İki birim arasında bir mirror (yansıtma) oluşturmak, gerçekten iyileştirme sağlayan çözümdür.

Sıkıştırma sunucuyu yavaşlatır mı?

lz4 genellikle sunucuyu hızlandırır. Sıkıştırılmış bloklar, daha az bayt yazılması ve daha az bayt okunması anlamına gelir; blok başına düşen CPU maliyeti, tasarruf edilen disk alanı yanında oldukça küçüktür. compression=lz4 değerini havuz kökünde ayarlayın, böylece her veri kümesi bunu devralır; ardından gerçek veriler yazıldıktan sonra zfs get compressratio tank değerini kontrol edin.