Seçim Rehberi · Linux ve Sistem Yönetimi
Ext4 veya XFS: Büyüme, Küçültme ve İş Yüküne Göre Seçim
Ext4 ve XFS farklı metadata ve ölçek davranışına sahip journaling dosya sistemleridir. Seçim dağıtım desteği, iş yükü, büyüme/küçültme ihtiyacı ve kurtarma araçlarıyla yapılır. “XFS her…
Teknik gözden geçirme:
Mimari ve çalışma modeli
Ext4 ve XFS farklı metadata ve ölçek davranışına sahip journaling dosya sistemleridir. Seçim dağıtım desteği, iş yükü, büyüme/küçültme ihtiyacı ve kurtarma araçlarıyla yapılır. “XFS her zaman hızlı” veya “ext4 her ortamda güvenli” genellemesi yerine aynı uygulama pilotu gerekir.
RHEL belgesindeki desteklenen XFS akışında büyütme vardır, küçültme desteklenmez; ext4 küçültme offline bakım gerektirebilir. Kernel ve dağıtımın destek koşulunu güncel sürüm için doğrulayın. Önce filesystem küçültmeden altındaki volume’u azaltmak veri kaybı doğurabilir.
Snapshot ve backup yetenekleri sadece filesystem adıyla belirlenmez; volume manager ve depolama katmanı da etkiler. Onarım aracı yedek yerine geçmez. Dosya sistemi göçünde izinler, extended attributes ve sparse dosyalar kabul testine dahil edilir.
- 1İş yükü ve büyüme
- 2Dağıtım destek matrisi
- 3Temsil edici pilot
- 4Göç ve restore
Tasarım parametreleri
- Büyüme planı
- Online büyütme ve muhtemel küçültme ihtiyacını baştan belirleyin.
- Metadata yükü
- Milyonlarca küçük dosya ile büyük sequential dosyalar için farklı pilot kullanın.
- Kurtarma
- Desteklenen check/repair araçlarını ve bağımsız restore süresini kaydedin.
Platformlardaki uygulama karşılıkları
Servis adları teknik karşılıklardır. Kapsam, varsayılanlar, bölge kullanılabilirliği ve işletim koşulları farklıdır; birebir aynı garanti anlamına gelmez.
| Ölçüt | Ext4 | XFS |
|---|---|---|
| Küçültme | Desteklenen offline akış olabilir | RHEL destek akışında yok |
| Büyüme | Dağıtım/sürüm araçları | Dağıtım/sürüm araçları |
| Performans | İş yüküyle ölçülür | İş yüküyle ölçülür |
Hesap ve uygulama örneği
İki yıl içinde 2 TB’den 8 TB’ye büyüyecek log volume’u ile periyodik küçültülecek lab volume’u aynı seçim gereksinimine sahip değildir. Temsil edici 100.000 dosya kopyasında create/stat/delete sürelerini ölçün. Backup restore sonrası ACL/xattr eşleşmesini kontrol edin.
Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Volume büyüdü, df değişmedi | Filesystem büyütme tamamlanmadı. | Block device ve filesystem boyutunu ayrı okuyun. |
| Göçte izinler bozuldu | ACL/xattr korunmamış. | Kaynak/hedef metadata ve servis erişimini karşılaştırın. |
Kabul ve doğrulama kontrolleri
- Dağıtım desteğini doğrulayın.
- Resize ihtiyacını yazın.
- Metadata pilotunu ölçün.
- Backup restore’u sınayın.
- ACL/xattr’ı doğrulayın.
- Göç geri dönüş planını hazırlayın.
İlgili kavramlar
Dosya sistemi ve depolama katmanları
Uygulama dizini, mount point, mantıksal disk ve fiziksel depolama aynı katman değildir. Boş alan kadar inode tükenmesi, read-only mount ve dosya sistemi hataları da yazmayı durdurabilir. Snapshot genellikle aynı depolama arızasını paylaşır ve bağımsız yedek sayılmaz. Mount seçenekleri ve kapasite genişletme yöntemi dosya sistemine göre değişir. İşletim sistemi yeniden açıldığında doğru depolamanın doğru dizine bağlandığını doğrulayın; mount edilmeyen dizine yazılan veri yanlış diski doldurabilir.
Kapasite ve kullanılabilir pay
Ham kapasite ile uygulamanın kullanabileceği kapasite aynı değildir. RAID veya erasure coding, dosya sistemi, ayrılmış alan, metadata, snapshot ve büyüme payı ayrı kalemlerdir. TB ile TiB gösterimi de görünür sayıyı değiştirir. Hesabı birimleriyle yazın ve önce kullanılabilir korumalı kapasiteyi, sonra işletim rezervini çıkarın. Ortalama doluluğu izlemek kadar büyüme eğimini izlemek de önemlidir. Tahmini dolma tarihi, yeni kapasiteyi satın alma ve devreye alma süresinden daha uzakta tutulmalıdır.
IOPS ve blok boyutu
IOPS saniyedeki I/O işlem sayısını, MB/s ise taşınan veri miktarını anlatır. Aynı IOPS sayısı farklı blok boyutlarında çok farklı bant genişliği üretir. Örneğin 10.000 işlem/s × 4 KiB yaklaşık 39,1 MiB/s eder. Okuma/yazma oranı, rastgele veya sıralı erişim ve veri koruma mekanizması sonucu değiştirir. Bir benchmark sonucunu üretim uygulamasına doğrudan taşımak yerine gerçek blok dağılımını ve eşzamanlılığı ölçün. Diskin yüksek IOPS göstermesi, uygulama yanıtının iyi olduğu anlamına gelmez; gecikme de birlikte incelenmelidir.
Gecikme dağılımı
Gecikme, bir işlemin başlangıcı ile yanıtı arasındaki süredir. Ortalama değer, az sayıdaki çok yavaş işlemi gizleyebilir; medyan ile p95/p99 gibi yüzdelikler farklı sorulara cevap verir. Ağ RTT, disk bekleme, işlemci sırası ve uygulama işlemesi toplam süreye katkıda bulunur. Ölçümün istemci tarafında mı sunucuda mı yapıldığını yazın. Gecikme artışının trafik yükselmesine, bakım işine veya kapasite sınırına denk gelip gelmediğini karşılaştırın. Bir eşik seçmeden önce normal yük ve yoğun saat için temel davranışı kaydedin.
Kalıcılaştırma ve güç kaybı
Commit edilmiş verinin güç kaybından sonra korunması veritabanı, işletim sistemi, dosya sistemi, kontrolcü ve diskin yazma garantilerinin birleşimine bağlıdır. Yazma önbelleği ve flush davranışını bilmeden performans için güvenlik ayarlarını kapatmayın. Güç kaybı korumalı depolama faydalıdır fakat bütün zincirin doğru yapılandırıldığını tek başına kanıtlamaz. Üretim yerine kontrollü laboratuvarda arıza ve recovery testi yapın. Veri bütünlüğünü örnek dosya açılmasıyla değil, uygulama kayıtları ve desteklenen tutarlılık kontrolleriyle doğrulayın.
Sürüm ve destek yaşam döngüsü
Bir ürünün kurulabilir olması üretim için desteklendiğini kanıtlamaz. İşletim sistemi, uygulama, sürücü, eklenti ve yönetim aracının uyumluluk zincirini birlikte kontrol edin. Güncelleme planında paket sürümü, destek bitişi, yeniden başlatma gereksinimi ve geri alma yöntemi bulunmalıdır. Test ortamı üretimdeki bağımlılıkları temsil etmezse sonuç yanıltıcı olabilir. Değişiklik sonrası yalnız sürüm numarasını değil, hizmet sağlığını ve önceki iş akışlarını doğrulayın. Bir sürümü sabitlemenin gelecekteki güvenlik düzeltmelerini engelleyebileceğini de dikkate alın.
Birincil teknik dokümantasyon
Doz Teknoloji teknik ekibi tarafından aşağıdaki birincil kaynaklar temel alınarak hazırlanmıştır. Hesaplar ve laboratuvar senaryoları varsayımlarını belirtir; uygulamadan önce kullanılan ürün sürümünü doğrulayın.