Linux Dosya Sistemleri (ext4, XFS ve Btrfs)

Bir Linux sunucusu kurarken çoğu kişi CPU, RAM ve disk boyutuna bakar ama diskin hangi dosya sistemiyle biçimlendirileceği sorusunu ya varsayılana bırakır ya da hiç düşünmez. Oysa dosya sistemi seçimi, sunucunun bir veritabanı altında nasıl davranacağını, milyonlarca küçük dosyayı ne kadar hızlı listeleyeceğini, disk dolduğunda ne kadar kolay büyütüleceğini ve bir çökme anında verinin ne kadar sağlam kalacağını doğrudan belirler. Yanlış seçim yıllar sonra "sunucu neden yavaşladı" sorusunun altında yatan görünmez sebep olabilir.

Bu rehberde Linux dünyasının en çok kullanılan üç dosya sistemini (ext4, XFS ve Btrfs) mimari düzeyde karşılaştırıyoruz. Journaling'in gerçekte ne yaptığından, büyük dosya ve çok sayıda küçük dosya senaryolarındaki performans farklarından, snapshot ve online büyütme yeteneklerinden başlayıp mkfs ile biçimlendirme ve tune2fs ile ince ayar komutlarına kadar iniyoruz. Amaç, "hangi senaryoda hangisini seçmeliyim" sorusuna kararsız bir tablo değil, net bir cevap verebilmek.

Dosya Sistemi Aslında Ne İşe Yarar#

Ham disk, aslında sırayla numaralandırılmış bloklardan oluşan devasa bir dizidir. Dosya sistemi, bu blokların üzerine bir düzen kurar: hangi blokların hangi dosyaya ait olduğunu, dizin ağacının nasıl kurulduğunu, her dosyanın izinlerini, sahibini ve zaman damgalarını tutar. Bu bilginin tutulduğu yapıya inode denir. Her dosya bir inode kaydına sahiptir ve inode, dosyanın verisinin diskte nerede durduğunu gösteren bir harita içerir.

İnode kavramı çoğu zaman göz ardı edilir ama pratikte çok önemlidir. Bir disk fiziksel olarak dolmadan da "disk dolu" hatası verebilir, çünkü inode sayısı tükenmiş olabilir. Bu durum özellikle çok sayıda küçük dosya barındıran e-posta sunucularında ve cache dizinlerinde yaşanır. İnode yönetiminin dosya sistemleri arasında nasıl farklılaştığı, seçim yaparken bakılması gereken kriterlerden biridir; bu konunun derinine disk kotası ve inode rehberinde ayrıca giriyoruz.

İkinci temel kavram journaling'dir. Bir yazma işlemi tam ortasında elektrik kesilirse, dosya sisteminin yarı yazılmış bir durumda kalmaması gerekir. Journal (günlük), yapılacak değişikliği önce ayrı bir alana kaydeder; işlem tamamlanınca günlük girdisi kapatılır. Çökme sonrası açılışta sistem günlüğe bakıp yarım kalan işlemi geri alır veya tamamlar. Bu sayede modern Linux dosya sistemlerinde saatler süren fsck taramaları büyük ölçüde tarihe karışmıştır.

ext4 — Güvenilir Varsayılan#

ext4, ext2 ve ext3'ün ardılı olarak yıllardır Linux dağıtımlarının çoğunda varsayılan dosya sistemidir. Olgunluğu, öngörülebilirliği ve geniş araç desteğiyle "hata yapmak istemiyorsan bunu seç" diyebileceğiniz seçenektir. Bir web sunucusu, tipik bir uygulama sunucusu ya da genel amaçlı bir VPS için ext4 neredeyse her zaman doğru ve güvenli tercihtir.

ext4'ün mimarisinde extent tabanlı bloklama kullanılır. Eski ext3'te büyük bir dosyanın her bloğu tek tek işaretlenirken, ext4 "şu bloktan başlayıp şu kadar blok bu dosyaya ait" şeklinde bütünsel aralıklar tutar. Bu, büyük dosyalarda hem daha az metadata hem daha hızlı erişim demektir. Ayrıca gecikmeli tahsis (delayed allocation) sayesinde yazılacak veri mümkün olduğunca geç ve toplu şekilde yerleştirilir, bu da parçalanmayı azaltır.

ext4'ün en önemli kısıtı, oluşturulduktan sonra küçültülemez olmaması değil, inode sayısının biçimlendirme anında sabitlenmesidir. Diski oluştururken kaç inode ayrılacağı belirlenir ve sonradan artırılamaz. Bu yüzden milyonlarca minik dosya barındıracağınızı biliyorsanız, mkfs aşamasında inode yoğunluğunu ayarlamanız gerekir. ext4'ün pratik dosya sistemi boyutu sınırı bir exabyte, tek dosya sınırı 16 terabyte civarındadır; bu değerler tipik hosting ve VPS iş yükleri için fazlasıyla yeterlidir. Barındırma planlarımızda ext4, web hosting ve WordPress hosting tarafında sessiz sedasız işini yapan varsayılandır.

XFS — Büyük Dosyalar ve Paralel İş Yükü#

XFS, başlangıçta yüksek hacimli ve çok iş parçacıklı iş yükleri düşünülerek tasarlanmış bir dosya sistemidir. Bugün RHEL, AlmaLinux, Rocky Linux gibi kurumsal dağıtımların varsayılanıdır ve büyük dosyalarla, yüksek paralellikle çalışan sistemlerde ext4'e kıyasla belirgin avantaj sağlar. Bir video işleme sunucusu, büyük veri ambarı, yoğun log toplayan bir sistem ya da tablespace'leri onlarca gigabyte'a çıkan bir veritabanı için XFS güçlü bir adaydır.

XFS'in en belirgin mimari özelliği allocation group (tahsis grubu) yapısıdır. Disk, bağımsız çalışabilen bölgelere ayrılır ve farklı iş parçacıkları farklı gruplarda aynı anda tahsis yapabilir. Bu, çok çekirdekli sistemlerde paralel yazma performansını ciddi biçimde yukarı taşır. Ayrıca XFS gecikmeli tahsisi agresif kullanır ve büyük sıralı yazmalarda son derece verimlidir.

XFS'in pratikte en çok konuşulan özelliği, canlı sistemde büyütülebilmesi ama küçültülememesidir. Bir XFS bölümünü çalışırken xfs_growfs ile büyütebilirsiniz; ancak diski küçültmek istiyorsanız yedekleyip yeniden oluşturmaktan başka yol yoktur. LVM veya bulut disklerinde alan yalnızca büyür yönünde değiştiği için bu kısıt çoğu senaryoda sorun olmaz. Yönetimli sunucu hizmetlerimizde disk düzenini kurarken, iş yükü büyük dosya ve yüksek paralellik içeriyorsa XFS'i tercih ediyoruz; sunucu yönetimi tarafında bu kararı sizin adınıza doğru gerekçelerle veriyoruz.

Btrfs — Snapshot ve Bütünlük Odaklı Modern Yaklaşım#

Btrfs, ext4 ve XFS'ten farklı bir felsefeyle tasarlanmıştır. Copy-on-write (CoW, yaz-üstüne-kopyala) mimarisi üzerine kuruludur: bir veri değiştirildiğinde eski blok üzerine yazılmaz, yeni bir yere yazılır ve metadata güncellenir. Bu yaklaşım, anında snapshot alma, blok düzeyinde sağlama toplamı (checksum) ile veri bütünlüğü doğrulama ve entegre RAID gibi yetenekleri mümkün kılar. Snapshot ihtiyacı olan, sık yedek/geri-al senaryoları yaşayan veya sessiz veri bozulmasına (bit rot) karşı ekstra güvence isteyen sistemler için Btrfs cazip bir seçenektir.

Btrfs'in en güçlü tarafı subvolume ve snapshot yönetimidir. Bir subvolume'un anlık görüntüsünü saniyeler içinde alabilir, bir güncelleme veya riskli değişiklik öncesi "geri dönüş noktası" oluşturabilirsiniz. Snapshot'lar CoW sayesinde başlangıçta neredeyse hiç yer kaplamaz; yalnızca değişen bloklar için alan kullanılır. Bu, sistem güncellemelerini ve dağıtımları çok daha cesur yapabilmenizi sağlar.

Bununla birlikte Btrfs, CoW mimarisi yüzünden bazı iş yüklerinde dezavantajlıdır. Yoğun rastgele yazma yapan veritabanı dosyaları (örneğin PostgreSQL veri dizini veya bir MySQL/InnoDB tablespace'i) CoW ile parçalanmaya eğilimlidir ve performans düşebilir. Bu yüzden veritabanı dizinlerinde CoW'u dosya bazında kapatmak (chattr +C) yaygın bir pratiktir. Btrfs olgunlaşmış olsa da özellikle RAID5/RAID6 kiplerinde geçmişte yaşanan sorunlar nedeniyle üretim ortamlarında hâlâ temkinli davranılır; RAID1 ve tekil disk kullanımı ise oldukça sağlamdır.

Üçünün Karşılaştırması#

Aşağıdaki tablo, üç dosya sistemini pratikte en çok fark yaratan boyutlarda özetliyor. Buradaki amaç mutlak kazanan ilan etmek değil, iş yükünüzle eşleştirebileceğiniz bir harita sunmak.

Kabaca bir kural olarak: kararsızsanız ve iş yükü "sıradan" ise ext4 seçin. Büyük dosyalar, yüksek paralellik ve kurumsal bir dağıtım varsa XFS'e geçin. Snapshot, geri alma ve veri bütünlüğü doğrulaması öncelikliyse ve veritabanı tarafını doğru yapılandırabileceğinizden eminseniz Btrfs değerlendirin.

mkfs ile Biçimlendirme ve İlk Kurulum#

Yeni bir disk ya da bölüm biçimlendirmek için mkfs ailesi kullanılır. Her dosya sisteminin kendi mkfs varyantı vardır. Aşağıda üç dosya sistemi için tipik komutları görebilirsiniz. Bu işlemin diskteki tüm veriyi sileceğini unutmayın; komutu çalıştırmadan önce hedef aygıtı iki kez doğrulayın.

# Mevcut blok aygıtlarını ve dosya sistemlerini listele
lsblk -f

# ext4 olarak biçimlendir, etiket ver
mkfs.ext4 -L veri /dev/sdb1

# Çok sayıda küçük dosya için inode yoğunluğunu artır
# (her 8 KB için bir inode — varsayılan genelde 16 KB'dir)
mkfs.ext4 -L mail -i 8192 /dev/sdb1

# XFS olarak biçimlendir
mkfs.xfs -L veri /dev/sdb1

# Btrfs olarak biçimlendir
mkfs.btrfs -L veri /dev/sdb1

Biçimlendirmeden sonra diski bir dizine bağlamanız (mount) ve kalıcı olması için /etc/fstab dosyasına eklemeniz gerekir. Aygıt adları yeniden başlatmada değişebildiği için UUID ile bağlamak en güvenli yöntemdir:

# Yeni diski geçici olarak bağla
mkdir -p /mnt/veri
mount /dev/sdb1 /mnt/veri

# Kalıcı bağlama için UUID öğren
blkid /dev/sdb1
# örnek çıktı: /dev/sdb1: UUID="a1b2c3d4-..." TYPE="xfs"

# /etc/fstab satırı (tek satır)
# UUID=a1b2c3d4-...  /mnt/veri  xfs  defaults,noatime  0  0

Buradaki noatime seçeneği küçük ama değerli bir ayardır: her dosya okunduğunda erişim zamanının diske yazılmasını engeller, böylece yoğun okuma yapan sunucularda gereksiz yazma yükünü ortadan kaldırır. Aynı diskte swap'a da ihtiyacınız olacaksa, dosya tabanlı swap kurulumunu Linux'ta swap alanı oluşturma rehberinden takip edebilirsiniz.

tune2fs ile ext4 İnce Ayarı#

ext4'ün güçlü yanlarından biri, biçimlendirdikten sonra bile birçok parametrenin tune2fs ile değiştirilebilmesidir. Bu araç yalnızca ext ailesi için çalışır; XFS'te karşılığı xfs_admin, Btrfs'te ise btrfs property komutlarıdır. tune2fs ile mevcut bir ext4 diskinin ayrıntılarını görebilir ve bazı davranışlarını yeniden yapılandırabilirsiniz.

# Dosya sisteminin tüm parametrelerini göster
tune2fs -l /dev/sdb1

# Etiketi değiştir
tune2fs -L yeni-etiket /dev/sdb1

# root için ayrılmış blok oranını %5'ten %1'e düşür
# (büyük veri disklerinde 5% çok yer kaybettirir)
tune2fs -m 1 /dev/sdb1

# Belirli sayıda mount veya süre sonrası otomatik fsck'yi kapat
tune2fs -c 0 -i 0 /dev/sdb1

Buradaki -m 1 ayarı özellikle veri diskleri için önemlidir. ext4 varsayılan olarak diskin yüzde 5'ini root kullanıcısına ayırır; bu, sistem diskinde mantıklıdır ama 4 TB'lık bir veri diskinde 200 GB'ın boşuna rezerve edilmesi demektir. Sistem diski olmayan disklerde bu oranı düşürmek güvenlidir. Bir ext4 diskin sağlığını kontrol etmek için ise fsck yalnızca disk bağlı değilken (unmounted) çalıştırılmalıdır; bağlıyken çalıştırmak veri bozulmasına yol açar.

Online Büyütme ve Küçültme#

Bir diski dolduğunda büyütmek, üretimde en sık yapılan işlemlerden biridir. Üç dosya sistemi de online büyütmeyi destekler ama küçültme konusunda ciddi farklar vardır. Genellikle disk, altta LVM veya bulut blok depolama üzerinde durur; önce fiziksel/mantıksal katman büyütülür, sonra dosya sistemi bu yeni alanı kapsayacak şekilde genişletilir.

# ext4 diski, altındaki alan büyütüldükten sonra genişlet
resize2fs /dev/mapper/vg-veri

# XFS diski çalışırken büyüt (mount noktası verilir)
xfs_growfs /mnt/veri

# Btrfs diski çalışırken büyüt (mount noktası verilir)
btrfs filesystem resize max /mnt/veri

Küçültme tarafında ise durum şudur: ext4'ü küçültebilirsiniz ama disk bağlı değilken (resize2fs ile hedef boyut vererek). Btrfs küçültmeyi canlı sistemde bile destekler. XFS'i ise küçültmek mümkün değildir; küçültmeniz gerekiyorsa yedekleyip yeniden oluşturmalısınız. Bu yüzden alan tahminini baştan geniş tutmak yerine, büyümeye açık bir mimari (LVM veya esnek bulut diskleri) kurmak daha sağlıklıdır. Yönetimli çözümlerde, disk büyütme ve dosya sistemi genişletme adımlarını kesintisiz uygulayabilmek için altyapıyı en baştan bu esneklikle kuruyoruz; ihtiyaç halinde tüm verinizi güvenli taşımak için site taşıma ve yedekleme hizmetlerimiz devreye girer.

Hangi Senaryoda Hangisi#

Teoriyi somut kararlara dönüştürelim. Aşağıdaki eşleştirmeler, yıllar içinde farklı sunucularda tekrar tekrar karşılaştığımız iş yükleri için pratik önerilerdir. Elbette istisnalar vardır, ama başlangıç noktası olarak güvenle kullanabilirsiniz.

• Genel amaçlı web sunucusu, tipik VPS, WordPress: ext4. Öngörülebilir, olgun, her araçla uyumlu. Paylaşımlı hosting ve sanal sunucu tarafında güvenli varsayılan.
• Büyük dosyalar, video, yedek deposu, veri ambarı: XFS. Büyük sıralı yazmada ve paralel iş yükünde üstün. VDS sunucu gibi kaynak yoğun senaryolarda tercih.
• E-posta sunucusu, cache, milyonlarca küçük dosya: ext4 (inode yoğunluğu artırılarak) ya da XFS. Burada inode planlaması dosya sistemi seçiminden daha kritik.
• Snapshot, sık geri alma, veri bütünlüğü önceliği: Btrfs. Ama veritabanı dizinlerinde CoW kapatılmalı.
• Veritabanı sunucusu (MySQL, PostgreSQL): XFS veya ext4. Btrfs seçilirse veri dizininde chattr +C şart.

Dikkat edilmesi gereken bir başka nokta, dosya sistemi seçiminin tek başına performansı belirlemediğidir. Altında SSD mi HDD mi olduğu, RAID kurgusu, mount seçenekleri ve uygulamanın I/O davranışı çoğu zaman dosya sistemi tipinden daha büyük fark yaratır. Bu yüzden "XFS ext4'ten hızlıdır" gibi genellemelere değil, kendi iş yükünüzü ölçmeye güvenin. Sunucu güvenliği ve erişim katmanını WAF ve DDoS koruma hizmetleriyle tamamlarken, doğru dosya sistemi seçimi de bu bütünün sessiz ama kritik bir parçasıdır.

Sıkça Sorulan Sorular#

ext4 mü XFS mi seçmeliyim, kararsızım?#

Kararsızsanız ve iş yükünüz sıradan bir web, uygulama veya WordPress sunucusuysa ext4 seçin; olgunluğu ve öngörülebilirliğiyle güvenli bir varsayılandır. Diskiniz büyük dosyalarla, yüksek paralellikle ve kurumsal bir dağıtımla (RHEL, AlmaLinux, Rocky) çalışacaksa XFS belirgin avantaj sağlar. İkisi de üretimde yıllardır sorunsuz kullanılan olgun sistemlerdir, dolayısıyla yanlış tercih yapıp felaketle karşılaşma riskiniz düşüktür.

Btrfs üretim ortamında güvenli mi?#

Btrfs, tekil disk ve RAID1 kiplerinde bugün oldukça olgun ve güvenlidir; snapshot, checksum ve subvolume yetenekleri sayesinde birçok senaryoda değerlidir. Ancak RAID5 ve RAID6 kiplerinde geçmişte yaşanan sorunlar nedeniyle bu kipler hâlâ temkinli karşılanır ve kritik verilerde önerilmez. Veritabanı gibi yoğun rastgele yazma yapan iş yüklerinde CoW'u ilgili dizinde kapatmadığınız sürece performans düşebileceğini de hesaba katmalısınız.

Dosya sistemini sonradan değiştirebilir miyim?#

Bir diskin dosya sistemini yerinde dönüştürmek genel olarak mümkün değildir; ext4'ten XFS'e ya da tam tersine geçiş için diski yedekleyip yeni dosya sistemiyle biçimlendirmeniz ve veriyi geri yüklemeniz gerekir. Bu yüzden dosya sistemi kararını kurulum aşamasında vermek çok daha az zahmetlidir. Geçiş yapmanız gerekiyorsa, kesintiyi en aza indirmek için yedekleme ve taşıma sürecini adım adım planlamak şarttır.

noatime seçeneği gerçekten fark yaratır mı?#

Evet, özellikle yoğun okuma yapan sunucularda somut fark yaratır. Varsayılan davranışta her dosya okunduğunda erişim zamanı damgası diske yazılır; bu, milyonlarca küçük okuma yapan bir e-posta veya cache sunucusunda gereksiz yazma trafiği oluşturur. noatime mount seçeneği bu yazmaları tamamen kaldırır ve pratikte hiçbir uygulamayı bozmaz, çünkü çoğu yazılım erişim zamanına ihtiyaç duymaz.

Disk dolu değil ama neden dolu hatası alıyorum?#

Bu klasik durum genellikle inode tükenmesinden kaynaklanır; disk fiziksel olarak boş olsa da inode sayısı tükendiğinde yeni dosya oluşturamazsınız. df -h diskin doluluğunu, df -i ise inode doluluğunu gösterir; ikincisi yüzde 100'e yakınsa sorun budur. Çözüm, çok sayıda küçük dosya barındıran dizinleri temizlemek ya da diski baştan daha yüksek inode yoğunluğuyla (mkfs.ext4 -i ile) biçimlendirmektir.

Kapanış#

Dosya sistemi seçimi, sunucu kurulumunun görünürde küçük ama etkisi yıllara yayılan kararlarından biridir. ext4'ün güvenilir varsayılanı, XFS'in büyük ve paralel iş yüklerindeki gücü ve Btrfs'in snapshot ile bütünlük odaklı modern yaklaşımı arasında doğru tercihi yapmak, iş yükünüzü tanımaktan geçer. Biçimlendirme, mount seçenekleri, inode planlaması ve büyütme stratejisini baştan doğru kurmak, ileride yaşanacak birçok performans ve alan sorununu daha doğmadan çözer.

Bu kararları tek başınıza vermek zorunda değilsiniz. Clou.TR olarak hem hazır web hosting ve WordPress hosting planlarımızda hem de tam kontrol istediğiniz VDS ve sanal sunucu çözümlerimizde, dosya sistemi ve disk düzenini iş yükünüze göre yapılandırıyoruz. Yönetimini bize bırakmak isterseniz sunucu yönetimi hizmetimizle tüm bu ince ayarları sizin adınıza yapıyor, düzenli yedekleme ile de verinizi güvence altına alıyoruz. İhtiyacınıza uygun çözümü belirlemek için ürün sayfalarımızı inceleyebilir, kararsız kaldığınız noktada ekibimize danışabilirsiniz.