Gönderen Konu: Yeni ext4 Disk Sistemi  (Okunma sayısı 1082 defa)

0 Üye ve 1 Ziyaretçi konuyu incelemekte.

Çevrimdışı fortran

  • Forum Gurusu
  • *****
  • İleti: 1.671
  • Bir insanı sevmekle başlar her şey...
    • get GNU
Yeni ext4 Disk Sistemi
« : 26 Nisan 2014, 06:42:26 ös »
Okuyacağınız yazı, 27 - 30 Temmuz 2007 tarihleri arasında Kanada'da düzenlenen Linux Sempozyumunda sunumu yapılmış "The new ext4 filesystem: current status and future plans" isimli yazının çevirisidir.

Bahadır A. HATUNOĞLU, Mert DEĞİRMENCİ ve Elif ERYILMAZ okumakta olduğunuz yazıyı çevirerek dilimize kazandırmışlardır. Çeviri sonrasında yazının genel kontrolü Mert DEĞİRMENCİ tarafından yapılmıştır. Teknik dille yazılmış, çevirisi zor bu çalışmayı bizlerle paylaştıkları için her birine ayrı ayrı teşekkürler...

ext4: Güncel Statü ve Geleceğe Yönelik Plânlar

Avantika Mathur, Mingming Cao, Suparna Bhattacharya
IBM Linux Technology Center
mathur@us.ibm.com, cmm@us.ibm.com, suparna@in.ibm.com
Andreas Dilger, Alex Tomas
Cluster Filesystem Inc.
adilger@clusterfs.com, alex@clusterfs.com
Laurent Vivier
Bull S.A.S.
laurent.vivier@bull.net

Özet

ext3 uzun yıllardır en çok kullanılan disk sistemi olmuştur. ext4 ise artan disk kapasiteleri ve "state-of-the-art" özelliği gereksinimleri ile ext3 disk sisteminin yeni jenerasyonu olarak geçen yıl oluşturulmuştur. Bu yeni disk sistemi ölçeklenirlikle performans artırımını birleştirmekle beraber, güvenilirliğini ve stabilitesini korumaktadır. ext4 daha geniş çeşitteki iş yükleri için uygun olacaktır ve "Linux disk sistemi" olarak ext3'ün yerini alacaktır.

Bu yazıda ext4 disk sistemine başlama nedenlerimizi anlatacağız. Ayrıca şu anda ext4 için ulaşılabilir ve planlanmış, artırılmış kapasiteleri keşfedip ext3 ile ext4 arasında yer değiştirme metodlarını tartışacağız ve son olarak da ext4 ile diğer disk sistemlerinin performansını üç ayrı özelliğe göre karşılaştıracağız.

1. Giriş

ext3 güvenilirliğinden, zengin özellik setinden, göreceli iyi performansından ve versiyonlar arası güçlü uyumluluğundan dolayı çok popüler bir Linux disk sistemi olmuştur. ext3'ün tutucu dizaynı onu stabil olması ve sağlamlığıyla ünlendirmesiyle beraber, geniş konfigürasyonlarda ölçekleme ve çalışma kapasitesini kısıtlamıştır.

Yeni donanımların artan kapasitesi ve ext3'ün çevrimiçi yeniden boyutlandırılmasının baskısı ile dikkatlerin ext3'e çevrilmesi ihtiyacını her zamankinden daha acil hâle getirmiştir. ext3'ün en göze çarpan kısıtlamalarından birisi 16 terabaytlık maksimum dosya sistemi boyutudur. Girişimci iş yükleri çoktan bu limite yaklaşıyorlar ve disk kapasitesinin her yıl ikiye katlanmasıyla beraber bir terabaytlık hard diskler piyasada kolayca bulunabilmektedir, aynı zamanda bu limit masaüstü kullanıcıları tarafından yakın zamanda kırılacaktır.

Bu kısıtlama için biz Ağustos 2006'da ext3'ün iki ana özelliği olan daha geniş disk sistemi kapasitesi ve uzantıların haritalandırılmasına yönelik bir yamalar serisi gönderdik. Bu yamalar kaçınılmayacak şekilde "on-disk" formatını değiştirirler ve ileri uyumluluğu bozarlar. Biz de ext3’ün büyük çaptaki kullanıcı tabanı için olan stabilitesini korumak için ext3'den ext4'e geçme kararı aldık.

Bu yeni disk sisteminin ana hedefi ext3'ün karşılaştığı ölçeklenirlik, performans ve güvenilirlik sorunlarına hitap etmektir. Bu konuda en çok sorulan soru neden XFS kullanılmadığı veya neden tamamen yeni bir disk sistemine başlanılmadığıdır. Biz ext2'den ext3'e geçerken de yaptığımız gibi çok sayıda ext3 kullanıcısının disk sistemlerini kolayca yükseltmelerini istiyoruz. Aynı zamanda ext3 ve e2fsk'nin yeteneklerine, sağlamlığına ve güvenilirliğine ciddi miktarda yatırım yapılmıştır. ext4 geliştiricileri bu geçmiş çalışmalardan avantaj elde edip yeni, gelişmiş eklentiler ekleme ve yeni ölçeklenebilir, girişime hazır disk sistemi geliştirme üzerine yoğunlaşabilirler.

ext4 bu nedenlerden ötürü doğdu. Bu yeni disk sistemi Linux’un 2.6.19 versiyonundan itibaren eklenmiştir. Bu yazıda da olduğu gibi, bu disk sistemi ext4dev başlığı altında, gelişmeye yönelik olduğu belirtilmiş ve kullanıcı üretim kullanımı için hazır olmadığını açık bir şekilde uyarılmıştır. Şu anda uzantılar ve 48-bit blok numaraları ext4'e eklenmiştir, ama yol haritasındaki çok sayıda yeni disk sistemi eklentileri bu yazıda ele alınacaktır. ext4'ün mevcut geliştirilme durumuna, git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 adresinde bulunan git revizyon kontrol sistemiyle ulaşabilirsiniz. Bugüne kadar yapılan uzantılar ve eklenti tartışmaları ext4'ün wiki sayfalarında bulunabilir.

Bazı gelişme aşamasında olan eklentiler büyük ihtimalle disk üstü planda değişmeye devam edecektir. Bu plan bittiğinde ext4 gelişme modundan stabil moda geçecektir. Bu zamanda ext4 genel kullanım için ext3’ün daha ölçeklenir ve modern versiyonuna ihtiyaç duyan kullanıcılara açılacaktır. Önümüzdeki üç kısımda ext4 için eklenen veya eklenmesi planlanan ölçeklenirlik, parçalama ve güvenilirlik alanındaki yeni eklentileri ele alacağız.

2. Ölçeklenirlik Artırımları

ext4'ün en önemli amacı daha ölçeklenir bir disk sistemi olmaktı. Bu bölümde ext4'te olacak ölçeklenirlik özelliklerine değineceğiz.

2.1. Geniş disk sistemi

Şu anki 16 terabaytlık disk sistemi boyutu limitinin sebebi ext3'teki 32 bitlik blok numarasıdır. Disk sistemi limitini artırmak için en kolay metot ise blok numaralarını göstermek için kullanılan bit sayısını artırmak ve verilerin veya verilerin verilerinin bloklarına olan referansları düzeltmektir.

Geçmişte ext3 için 48 bitlik blok numaralarını destekleyecek kapasitede büyüklük yaması vardı. ext4'te ise, ext3'ün güncel dolaysız blok haritalandırmasına dayanan blok numaralarının 64 bite genişletilmesi yerine, geliştiriciler büyüklük haritalandırmasını 48 bitlik blok numaralarıyla kullanmaya karar verdiler. Bu hem kullanılabilecek disk sistemi kapasitesini, hem de büyük dosyalardaki verimliği arttırır. 48 bitlik blok numarasıyla, ext4 4 kilobaytlık blok boyutuyla beraber 1 Eksabaytlık ( 2(48+12)=260 ) maksimum disk sistemi boyutunu destekleyebilmektedir.

Veri blok numaralarını 48 bite değiştirdikten sonraki adım verilerin verilerine (metadata) olan referansları karşılıklı düzeltmekti. Verilerin verisi (metadata) süperblokta, grup açıklayıcısında ve günlükte bulunmaktadır. Süperblok yapısının sonuna blok sayıcı değişkenleri(s_free_blocks_count, s_blocks_count ve s_r_blocks_count) için en belirgin 32 biti saklamak ve onları 64 bite artırmak için yeni alanlar eklendi. Benzer şekilde, inode çizelge göstergeleri ve bit haritaları için en belirgin 64 bit değerini saklamak üzere blok grup açıklaycısında yeni 32 bitlik alanları ileri sürdük.

Modifiye edilmiş blokların adresleri günlüğe girildiği için, blokları günlüğe tutan katmanın (journaling blok layer, JBD) en az 48 bitlik blok adresini desteklemesi gerekir. Bu yüzden ext4 projesi oluşmaya başladığında, 32 bitlik blok numarasını desteklemek için JBD, JBD2'ye yükseltilmiştir. Şu anda JBD2'yi sadece ext4 kullandığı halde, JBD2 hem 32 bitlik hem de 64 bitlik disk sistemleri için genel güncelleme sağlayabilmektedir.

Birileri neden 64 bitlik full destek yerine 48 bitliği kullandığımızı sorabilir. 1 eksabaytlık limit yıllarca yeterli olacaktır. Bu limitin kırılmasından çok önce güvenilirlik sorunlarının gündeme gelmesi gerekmektedir. Şu anki hızlarla, 1 eksabaytlık sistemin bir tam e2fsck'yi bitirmesi 119 yıl alacaktır, ve 64 zettabaytlık (264 blok) bir disk sistemi için bunun 65536 katı süre gerekir. Bu tür sorunlarının üstesinden gelmenin geliştiriciler için tam 64 bitlik desteğini ele almaktan daha öncelikli olduğu yazımızda daha sonra ele alınacaktır.

2.1.1. Gelecek Çalışmalar

32 bitlik blok numarası tarafından oluşturulan limiti artırdıktan sonra disk sistemi kapasitesi disk sistemindeki blokların sayısı tarafından hâlâ sınırlandırılmıştır. ext3’te güvenlik endişelerinden dolayı bütün blok grubu açıklayıcılarının kopyaları ilk blokta saklanmaktadır. 4.1.bölümde ele alınan ve yeni "önceden belirlenmemiş blok grubu özelliği" eklentisiyle birlikte, yeni grup açıklayıcısının boyutu 64 bayttır. Varsayılan 128 Megabyte'lık (227 byte) blok grubu boyutu sayesinde, ext4 en fazla 227/64 = 221 blok grubuna sahip olabilir. Bütün disk sistemine olan limitler 256 terabayta (221+227=248 byte) kadardır.

Bu probleme çözüm bütün 2.6 dağıtımları için ext3’te zaten olan metablok grup eklentisini (META_BG) kullanmaktır. META_BG eklentisi ile beraber ext4 disk sistemleri birçok metablok gruplarına bölünmüştür. Her bir metablok grubu grup açıklayıcısı tek bir disk bloğunda saklanabilen blok kümelerinden oluşmuştur. ext4 disk sistemleri için tek bir metablok grubu bölünmesi 64 blok grubu veya 8 Gigabyte'lık disk alanı içerir. Metablok grup eklentisi grup açıklayıcısının yerini tıkanık olan bütün disk sisteminin ilk blok grubundan her metablok grubunun kendi ilk grubuna taşır. Yedekler ise her metablok grubunun ikinci ve sonuncu grubunda bulunurlar. Bu maksimum blok gruplarını 221'den 232'ye çıkararak, disk sistemine bir exabaytlık destek sağlar.

2.2. Kapsamlar

ext3 disk sistemi mantıksal bloklardan disk bloklarına birebir geçiş sağlayan dolaylı blok haritalandırma düzeni kullanır. Bu düzen seyrek ve küçük dosyalarda çok verimlidir, fakat daha geniş dosyalarda ek yükler getirir, özellikle silme ve kesme işlerinde kötü çalışır.



Önceden de belirtildiği gibi kapsam haritalandırması ext4’te bulunmaktadır. Bu yaklaşım büyük ve bitişik dosyalar için mantıksal bloklardan fiziksel bloklara geçerken verimli haritalandırma yapar. Kapsam bir aralıktaki bitişik fiziksel blokları temsil eden tek açıklayıcıdır. Şekil 1 kapsamların yapısını göstermektedir. Önceden de bahsettiğimiz gibi kapsam yapısındaki fiziksel blok alanı 48 bit alır. Tek bir kapsam 215 adet bitişik bloğu veya 4 kilobaytlık blok boyutuyla 128 megabayt'ı temsil eder. Kapsamın MSB'si önceden belirtilmemiş kapsamları işaretlemek için kullanılır, bu olayda 3.1.kısımda anlatacağımız önceden tahsis etme eklentisi için kullanılır.



 Dört kapsam, ext4 inode yapısının içinde direkt olarak saklanabilir. Bu genellikle küçük veya bitişik dosyalar için yeterlidir. Daha geniş, çok parçalanmış veya ayrık dosyalar içinse daha çok kapsam gerekmektedir. Bu ağacın kökü ext4 inode veri yapısında saklanmaktadır, kapsamlar ise ağacın yaprak düğümlerinde saklanmaktadır. Ağaçtaki her düğüm, düğümdeki uygun girdilerin sayısını, düğümün saklayabileceği girdilerin kapasitesini, ağacın derinliğini ve sihirli sayıyı içeren kapsam başlığı ile başlar (Şekil 2). Sihirli sayı (Magic Number), eklentiye yeni artırmalar yapıldıkça (64 bitlik blok numaralarına artırılması gibi) kapsamların farklı versiyonlarını ayırt etmek için kullanılabilir.

Kapsam başlığı ve sihirli sayı (magic number) ayrıca veri dosyalarının disk üstü yapılarında çok ihtiyaç olan sağlamlığı da kazandırır. Çok ufak dosya sistemlerinde, blok haritalandırmalı dosyalar, inode'lardaki herhangi bir bozulmanın hemen tespit edilebileceğine dayanır. Çünkü geçerli dosya sistemi blok sayısı 32-bit tam sayının alt kümesi kadar olacaktır. Büyüyen disk sistemi boyutlarıyla beraber dolaylı bloktaki rastgele bozulma blok numaralarından kendi kendine ayırt edilemez. Kapsam başlığında bulunan basit sihirli numaraya ek olarak, kapsam ağacının yapısı çalışma zamanında veya e2fsk tarafından çeşitle yollarla doğrulanabilir. "ext4_extent_header" kendi iç tutarlığıyla beraber (eh_entries ve eh_max) aynı zamanda disk sistemi bloğu boyutuna da dayanır. "eh_depth" kökten yapraklara gittikçe azalır. Bir yaprak bloğundaki "ext4_extent" girdileri artan "ee_block" numaralarına sahip olmalı ve komşuları "ee_len ile örtüşmemelidir. Benzer biçimde "ext4_extent_idx" de artan "ei_block" değerlerine sahip olmalıdır ve indeksin örttüğü blok aralığı kapsam yaprağındaki asıl blok aralığına karşı doğrulanabilir.

Günümüzde kapsam haritalandırması ext4’te "extents" monte seçeneğiyle mümkün kılınmıştır. Disk sistemi monte edildikten sonra her yeni dosya kapsam haritalandırması ile oluşturulabilir. Kapsam haritalarının yararları 7.kısımdaki performans değerlendirmesine yansıtılmıştır.

2.2.1. Gelecek çalışmalar

Kapsamlar ayrık veya çok bölünmüş dosyaları göstermede çok verimli değillerdir. Çok bölünmüş dosyalar için "block-mapped extent" adında yeni tip kapsam öne sürebiliririz. Kapsam başlığında saklanan yeni bir sihirli numara ext3'ün dolaylı bloğuna benzer, tahsis edilmiş blok numaraları listesini taşıyan yeni tip yaprak bloğunu ayırt eder. Bu bize blok halinde eşleşmiş düzenin tahsisinde esneklikle beraber kapsam formatına artırılmış sağlamlık katar.

Disk üstü verinin sağlamlığını geliştirmek için kapsam bloklarında, kapsam başlığına ek olarak "kapsam kuyruğu" oluşturulması önerilebilir. Kapsam kuyruğu, inode numarasını, bloğu tahsis eden inode'un üretimini ve kapsam bloğunun toplamının kendisini (ama veriyi değil) içerebilir. Bu toplam içerdeki bozulmayı ve blok numarası orada bulunursa eksik yazımları tespit edebilir. Inode numarası ağacın yanlış göstermesine yol açan bozulmayı tespit etmede kullanılabilir (daha büyük seviyelerde bozulma olsa veya eksik yazımlar olsa bile). Inode numarası aynı zamanda bozulmuş inodun verisini yeniden kurmakta veya silinmiş bir dosyayı çevirmekte ve bölme için blokların ters eşlenmesinde kullanılabilir.

2.3. Büyük boyutlu dosyalar

Linux’ta dosya boyutu "i_blocks" sayaç değeri temel alınarak hesaplanır. Fakat bu ünite disk sistemi blok boyutu yerine(varsayılan 4096 bayt) kesimler hâlindedir (512 bayt). Ext4'ün "i_blocks"u inode yapısında 32 bitlik değişken olduğu için bu maksimum dosya boyutu limitini 2 terabayta ulaştırır. Bu aynı zamanda ext3'ün bir süredir plânladığı ölçeklenirlik limitidir. Ext4 için çözüm gayet basittir. İlk kısım sadece ext4 inode'daki "i_blocks" ünitelerini disk sistemi bloklarına çevirmekten ibarettir. Bir "ROCOMPAT" eklenti işsretleyicisi olan "HUGE_FILE" i_blocks'ların bazı inode'larda disk sistemi bloğu üniteleri halinde bulunduğunu göstermek için ext4’e eklenmiştir. Bu inode'lar aktif inodlara i_blocks'ları full disk sistemi değişimi olmadan 512 baytlık üniteler halinde saklama olanağı vermek için "EXT4_HUGE_FILE_FL" hâlinde işaretlenir. Buna ek olarak bazı ayrılmış inod alanlarını kullanarak "i_blocks" değişkeni 48 bite kadar artırılır. Biz bu kapsam düzeniyle 32 bitlik mantıksal blok numaralarıyla sınırlandırılmış durumdayız, bu da dosya boyutu limitin, 16 terabayt ile sınırlandırmaktadır. Gelecekte esnek kapsam düzeniyle bu limiti ortadan kaldırabilir ve dosya boyutunu daha da artırmak için 48 bitlik i_blocks'ları tamamen kullanabiliriz.

2.4. Çok sayıda dosya

Bazı uygulamalar zaten milyarlarca dosya oluşturmakta ve trilyonlarca dosya için destek istemektedir. Teoride, ext4 disk sistemi 32 bitlik inode numarasıyla milyonlarca dosyaya destek verebilir. Fakat pratikte bu limite kadar ölçekleme yapamaz. Bunun sebebi ext4'ün ext3'ü takip ederek hâlâ inode çizelgelerini statik olarak bölmesidir. Bu yüzden inodların sayısı disk sistemini oluştururken belirlenmek zorundadır. Kullanıcılar ileride inode'lardan mahrum kalmamak için ilk başta çok sayıda inode seçerler. Bu da kullanılmayan inode yapılaırını saklamak için gereksiz disk alanı demektir. Boşa harcanan alan ext4'te daha geniş varsayılan inode'la beraber daha belirgin hale geldi. Bu aynı zamanda geniş dosya sistemlerinin yönetimi ve tamirini olması gerekenden daha zor bir hale getirdi. Önceden belirtilmemiş grup eklentisi bu sorunu bir yere kadar idare edebilir fakat çok kullanılan disk sistemlerinde kullanılmayan inode'lar karışabilir ve bütün disk sistemine yayılabilir.

ext3 ve ext4 geliştiricileri bir süredir dinamik inode paylaşımını desteklemeyi düşünüyorlar. Bu konu hakkındaki üç genel düşünce şöyledir:

    * Performans: Bizim, inode yapısının saklanığı yerde inode numarasının bloğa verimli bir şekilde çevrildiği bir yola ihtiyacımız var.
    * Sağlamlık: e2fsck, disk sisteminin bozulmaya uğradığı durumda inode çizelge bloklarını disk sisteme yayılmış bir şekilde konumlandırabilmelidir.
    * Uyumluluk: Biz fazlalık sonucu olabilecek inode numarası çarpmasını 64 bitlik inode numarası ile 32 bitlik sistemler üzerinden ele almalıyız.

Bu üç gereksinim dizaynı ilgi çekici kılmaktadır.



 Dinamik inode tablolarıyla, inode yapısını depolayan bloklar, artık sabit bir yerde değildir. XFS'de olduğu gibi, blok sayısının inode sayısına direkt olarak kodlanması, inode sayısının verimli bir şekilde haritalanması ve blokta depolanması için bir yoldur. Bu, 64-bit inode sayısının kullanımını imâ eder. Inode sayısının beş bitlik kısmından en alttaki dört bit, inode tablo bloğunun içindeki ofset parçaları depolar. Şekil 3'de gösterildiği gibi, kalan grubun içinde ilişkili 15-bitlik blok sayısına ek olarak 32-bit blok grup sayısını depolar. Sonra, komşu inode tablo bloklarının bir kümesi (ITBC), talep olduğu takdirde diğerlerinden ayrılabilirler. ITBC'in başında bir bitmap olsaydı, kullanılmış ya da serbest haldeki inode'ları tutmak için kullanılabilir, hızlı inode ayırmasına ve serbest bırakılmasına olanak verebilirdi.

Dosya sisteminin bozulduğu bir durumda, inode tablolarının çoğunluğu, dizin girişleri kontrol edilerek saptanabilir. Güvenilirlik konusu daha fazla düşünüldüğünde, sihirli bir sayı (magic number), ITBC'in başında depolanabilir. Bu metadata bloğunu tanımak için e2fscke yardım eder.

Inode'u tekrar yerleştirmek, blok sayısının inode sayısının içinde olması önerisiyle birlikte zor bir duruma gelir. Eğer dosya sistemi tekrar boyutlandırılırsa veya birleştirilirse, biz bütün kaynaklarını değiştirmeyi gerektirecek olan inode sayılarının olduğu inode bloklarının yerini değiştirmek zorunda olabiliriz. Gerçekte depolanan inode un olduğu yerde yaşlı bir blok inode sayısını yeni bir blok sayısına çeviren gruba sahip olmak ve bunu kapsayan "Inode istisna haritası" hazırlamak bu düşünce için bir öneridir. Inode hareket ettirilmediği takdirde, harita genellikle boş olacaktır.

64-bitlik inode sayısıyla ilgili bir konu da, 32-bitlik uygulamaların mümkün olan inode sayılarla çarpışma ihtimalidir. Bu uygulamalar hâlâ, 32-bitlik stat() içinde, inode'a erişmek ve kırmak için kullanılıyor olabilir. Araştırma,bu durumun yaygın olduğunu görmek için ve uygulamaların çoğunun, 64-bitlik parçayı stat64()'de kullanmak için güncel olarak tutturulmuş olup olmadığını gösterir. Bu konu için bir yol da, 32-bitlik platformlarda 32-bitlik inode sayısını oluşturmaktır. On yedi bit, 32-bitlik mimaride blok grup sayılarını yeteri kadar temsil etmektedir, ve biz, 32-bitlik inode sayısını inşa etmesi için bir blok grubunun ilk 210 bloğuna inode tablo bloklarını sınırlayacağız. Bu şekilde kullanıcı uygulamaları, 32-bitlik platformdan alınacak olan benzersiz inode sayılarını garanti edilecek. ext4 üretimde oluncaya kadar, 32-bitlik uygulama 64-bitlik platformda ilerlerken biz bu uygulamanın ayarlanacağını umuyoruz ve bu sadece dosya sistemi 1 TB'ın üzerine çıktığında olacaktır.

Özet olarak, dinamik inode ayrımı ve 64-bitlik inode sayısı, ext4 te büyük birçok dosyayı desteklemek için ihtiyaç duyulacak bir durumdur. Yararlar açıktır ama disk biçimindeki değişiklikler, bu durum için zorlayıcı olabilir. Tasarımın ayrıntıları hâlâ tartışma konusudur.

Çevrimdışı fortran

  • Forum Gurusu
  • *****
  • İleti: 1.671
  • Bir insanı sevmekle başlar her şey...
    • get GNU
Ynt: Yeni ext4 Disk Sistemi
« Yanıtla #1 : 26 Nisan 2014, 06:42:54 ös »
2.5. Dizin Ölçeklenebilirliği

ext3'te tek bir dizinin içerdiği alt dizinlerin maksimum sayısı 32.000'dir. Bu sınır, ext4'te sınırsız alt-dizin desteği ile birlikte ortadan kaldırılacaktır.

Birçok giridisi olan büyük dizinleri desteklemek için, dizin indeksleme özelliği[6], ext4'te mevcut. ext3'teki eksiklik ise, dizin girdileri, dizinler için çok verimsiz olan bir listede depolanır. Dizin indeksleme özelliği, girdileri, derinliği sabit 32 bitlik hashleri kullanan BTree yapısında özelleşmiş HTree data yapısında tutar. HTree'nin hızlı arama zamanı, büyük dizinlerde performansı geliştirir. 10.000 dosyadan daha fazla olan dizinler için, hız ortalama 50-100 kat artar.[3]

2.5.1. Gelecekte yapılacak iş

HTree uygulaması, bir ağaç aramasının ext2 dizin biçimine uyumlu olarak doğrusaldan geliştirilmesine izin verirken, diğer yandan bu yaklaşım içinde sınırlamalar da vardır. HTree uygulaması, 2 düzey ağaçla indekslenebilen 510*511 4 KB dizin yaprak bloğuyla (yaklaşık olarak 25M-24M byte dosya adları) sınırlıdır. 3.düzeyde HTree'ye izin vermek için kodu değiştirmek mümkün olabilir. Ayrıca genel olarak dizinlerde 2 GB dosya boyut sınırı vardır. Çünkü yüksek 32-bit i kullanmak için hazırlanan kod ve dizinlerdeki i_size, 2 GB sınırının sadece düzenli dosyalar için ayarlandı.

Aslında karmaşıklık içinde, indekslenen dizinlerde dosya adlarının aranması işi, inode’ların ayrık halde bulunduğu çizgisel dizilimle kıyaslanırsa, bunun neden rastgele yapılması gerektiği görülür. Çok fazla inode u olan büyük diskleri aramak için tek yol, rastgele aramalar yapmak.

Karışık-indeks diziminde readdire sahip olmak bir ihtiyaçtır. Çünkü dizin girişleri, bir dizin yaprak bloğunun ayrılması esnasında hareket edebilir bundan dolayı POSIX isteklerini karşılayabilmek için tek yol karışık dizinde emniyetli bir şekilde taramaktır.

Bu problem için bir çözüm, ayrı bir inode'u referans gösteren adil bir dizin girişinin yerine dizine tüm inode u koymaktır. Bu, inode bir readdir yaptığı zamanda inode un arama yapması için olan ihtiyaçtan kaçınır, çünkü tüm inode, zaten hafıza içinde readdir adımında okunmuştur. Eğer dizini yapan bloklar, verimli bir şekilde ayrılırsa, sonra dizini okumak herhangi bir aramayı gerektirmez.

Bu ayrıca, dinamik inode ayrımına izin verecek, dizini inode tablosunun saklayıcısı hâline getirecektir. Inode sayıları (önceden tartışılan 2.4 bölümünde ) benzer bir biçimde oluşturulacak. Bu sayede bir inode un oturduğu blok, inode'un kendini saymasıyla saptanabilecek. Zor bağlanan dosyalar, aynı bloğun, aynı zamanda çeşitli dizinlere ayrıldığını gösterir, bu sorun da inode’un içindeki link sayacıyla düzeltilebilir.

Ayrıca inode’un içinde bir veya daha fazla dosya deplomak durumunda olabiliriz. Bu da EA (extended attribute) sayesinde gerçekleştirilebilir. Böylece readdir yaparken tek bir dizinle alakalı inode'ların ismini bulup, diğer inode'ları atlayabiliriz. Verimli bir inode adı araması için, ext3'te kullanılana benzer bir Htree kullanıyoruz (her dizin bloğu için bir girdi istemek yerine, her ad için bir girdi istiyor). Fakat girdilerin (inode'ların kendileri) directory büyüdükçe değişmediklerini göz önünde tutarsak, readdir için disk block veya directory offset komutunu verebiliriz.

2.6. Büyük Inode ve hızlı uzantı nitelikleri

ext3, farklı inode boyutlarını destekler. Inode boyutu, düzenleme zamanında mke2f-I [inode boyutu] seçeneği kullanılarak, 128 byte'tan büyük olmak üzere ikinin herhangi bir kuvvetinden dosya sisteminin blok boyutuna kadar ayarlanabilir. Veriyle dolu olan ve yeni alanlar için az boşluğa sahip olduğu varsayılan inode yapı boyutu 128 byte'tır. Ext4'te, varsayılan inode yapı boyutu, 256 byte olacaktır.



 Çekirdek ve e2fsck'te birçok kodu kopyalamaktan kaçınmak için, büyük inode lar, ilk 128-byte için, yapıyı Şekil 4'te gösterildiği gibi tutarlar. Inode'un kalanı, iki parçaya ayrılır: bütün Inode'ların alanlarının toplamasına izin veren bir tutturulmuş-alan kısmı (nanosaniye zaman niteliği gibi, (5.bölüm)); ve inode'un kalanını tükettiği hızlı uzantı nitelikleri (EAs) için bir kısım.

Inode'un sabit-alan parçası, kernelin tanıdığı alanlar üzerine kurulmuş, dinamik olarak boyutlandırılmıştır .Bu alanın boyutu, orijinal 128-byte'lık inode'un önündeki ilk yerde, i_extra_isize denilen bir alanda saklanır. Superblock ayrıca s_min_extra_isize ve i_want_extra_isize olmak üzere 2 alan içerir. Bu düşük seviyeli çekirdeklerin daha büyük i_extra_isize ı ayırmasına izin verir.

S_min_extra_isize her biri inode içinde sabit-alan boşluğunun garanti edilen minimum miktarıdır. S_want_extra_isize yeni inode da sabit-alan boşluğunun istenen miktarıdır. Fakat bu kadar boşluğun, her inode varolup olmadığının hiçbir garantisi yoktur. ROCOMPAT özelliği olan EXTRA_ISIZE , superblok alanlarının geçerli olup olmadığını belirler. Ext4 kodu yakında , i_extra_isize’ı dinamik olarak kullanarak sabit alanları ihtiyaç duyduğunda genişletebilecek.Bunu yaparken, hızlı EA'sı olan boşluklar lâzım .Aksi taktirde bunları başka bir EA bloğuna taşır.

Kalan büyük inode boşluğu, inode'un içinde EA verisini depolamak için kullanılabilir. EAs'nın önceden hafızada olmasından dolayı, inode diskten okunduktan sonra,bu harici EA bloğunun zahmetli bir şekilde aranmasını önler. Bu büyük ölçüde, EAs'ı kullanan uygulamaların performansını geliştirebilir, bazen 3'ün 7'ye kadar olan faktörü kadar olabilir.[4].

Harici bir EA bloğu, her dosya için EAs'ın 4 KB'ının üstüne depolamaya izin veren hızlı EA boşluğuna ek olarak hala uygundur.

Büyük inode'larda hızlı EAs için destek, 2.6.12'den beri Linux çekirdeklerinde mümkün oldu, fakat birçok insanın, mke2fs zamanında olan bu yetenekten haberdar olmaması bu yöntemin nadiren kullanılmasına yol açtı. Ext4'ün, daha büyük inode'lara sahip olacak olması bu varsayılan özellik ile sağlanacak.

Ayrıca, daha büyük veya daha çok EAs'ı depolamak için,4 KB EA sınırını aşmak da tartışılıyor. Büyük ve tek olan EAs'ların (herhangi bir boyutta EAs'ya izin vermek için) kendi içindeki inode'larda depolanması olasıdır. Ayrıca birçok EAs, dizin-gibi bir yapıda depolanacak olduğundan, ext4 diziniymiş gibi aynı kodları uygulamak yada küçük değerleri inline kaydetmek mümkün.

3. Blok yerleşimlerinin genişletilmesi

Dosya sistemi işlem hacmini artırmak, modern dosya sistemleri için en önemli amaçtır. Bu amaç için, geliştiriciler sürekli, dosya sisteminin parçalara ayrılmasını azaltmayı deniyor. Yüksek parçalara ayrılma oranları, toplam işlem hacmini etkileyen daha büyük disk erişim zamanına sebep olur. Ayrıca artan metadata yükü, verimsiz haritalama demektir.

Kendisini haritalayan mevcut alanlardan faydalanan ve blok ayırma tekniklerini geliştirerek dosya sisteminin parçalara ayrılmasını azaltması hedeflenen ext4, yeni özellikler de sunmaktadır.

3.1. Kalıcı rezerve edilen alanlar

Bazı uygulamalar, veritabanları ve sürekli medya sunucuları, blokları geçerli bir datayla veya sıfırlarla başlatmaya gerek duymadan, dosyanın üstünde bulunan (tipik olarak işlem gören dosyanın boyutunun arttırılması sırasında) ön ayrışım yapan blokların yeteneğinden faydalanır. Preallocation (önceden tahsis etmek), dosya içinde bitişik ayrışımların devam etmesini sağlar (zamandan ve datanın gerçekte hangi düzende yazıldığından bağımsız olarak) ve yazmak için gerekli alanı tahsis eder. Bir uygulamanın, dosyanın, ne kadar boşluğu gerektireceğinin ön bilgisi olursa bu bilgi kullanışlı olabilir. Dosya sistemi içinde preallocation'u yorumlar, ama henüz dosyanın başlatılmamış kısımlarını (sıfır dolu blokları) yorumlayamaz. Böylelikle ,bir sonraki yazma işlemi başlamadan, her blok için ortaya çıkan eski veriden kaçınılır. Preallocation, reboot'lar karşısında, ext3 ve ext4'teki blok rezarvasyonlarından farklı olarak, sürekli ve tutarlı olmalıdır.[3]

Sıralı yazma işlemi içeren uygulamalar için, dosyanın başlatılan veya başlatılmayan kısımlarını birbirinden ayırmak mümkündür. Bu, başlatılmış kısmın boyutunu temsil eden en yüksek nokta değerini koruyarak yapılabilir. Fakat, önceden tahsis edilen alanlara rastgele yazma işlemi yapan veritabanları ve diğer uygulamalar için bu, yeterli değildir. Dosya sisteminin, dosyanın ortasında ki başlatılmamış blokların sınırlarını bilmesi gerekir. Bu yüzden, bazı alan temelli dosya sistemleri, örneğin XFS ve şimdi de ext4 gibi, verilen bir dosya için rezerve edilmiş fakat başlatılmamış alanları işaretleme seçeneği verir.

Örneğin Ext4, MSBi'ni kullanarak bu verilmiş alanın, başlatılmış veriyi içerip içermediğini gösterir (Şekil 1). Okuma esnasında başlatılmamış bir alana sadece bir delik gibi davranılır, öyle ki VFS, sıfır-doldurulan dosya bloklarıyla döner. Yazılanların üzerindeki alan, başlatılmış ve başlatılmamış alanlara ayrılmalıdır, eğer bu alanlar komşuysa, bitişik başa döndürülen bir alanla başlatılmış kısım birleştirilmelidir.

Şimdiye kadar, XFS, ön-tahsis (preallocation) yapan diğer Linux dosya sistemlerinin uygulamalarına bir ioctl arayüzünü sağladı. Ext4 gibi dosya sistemleri ile, fallocate için ortak bir sistem-çağrı arayüzü sağlandı ve ilgili bir inode çalışması başlatıldı. Bu, posix 'fallocate API'i kullanan uygulamalar ile dosya sisteminin ön ayrışma ile ilgili özel görevleri yerine getirmesi sağlandı.

3.2. Ertelenen ve çoklu blok yerleşimi

 ext3'te bir yazım işlemi sırasında blok yerleştirici sadece bir blok yerleştirebilir. Bu büyük giriş-çıkışlar için verimsizdir. Blok ayırma isteklerinin, bir zamanda VFS tabakaları boyunca geçmesinden, ext3 bunu önceden göremez ve gelecek olan istek kümelerini algılayamaz. Bu ayrıca dosyanın parçalara ayrılması (fragmentation) olasılığını arttırır.

Ertelenen yerleşim (delayed allocation ), blok tahsisatının yazma işlemide yapılması yerine numaralamak için ertelendiği bir tekniktir. Bu metod birçok blok ayrışım isteğini birleştirerek tek bir istek haline getirmek için fırsat sağlar, olası parçalanmaları azaltır ve CPU’a düşen işlem sayısını azaltır. Ertelenen yerleşim ayrıca kısa ömürlü dosyalar için gereksiz blok ayrımlarından kaçınarak verimlilik sağlar.

ext4 ertelenen yerleşim yamaları son zamanlarda uygulanmaktadır, fakat bunu destekleyen VFS tabakasının hareketi zordur. Yani, çoklu dosya sistemleri bu özellikten yararlanabilirler.

Ertelenen yerleşim desteğiyle, tampon giriş-çıkışlar için çeşitli blok ayrımları, mümkündür. Çeşitli komşu bloklar içeren bütün bir alan, bir zamanda tek bir blok yerleştirilmesi yerine bir seferde yerleştirilir. Bu, ext4_get_blocks ve ext4_new_blocksand içindeki çeşitli çağrıları çıkarır, ve CPU kullanımını azaltır.

ext4 çoklu blok ayrımı, blok grubu başına alan bilgisi inşa eder ve disk bloğunun temel aldığı bit haritasını özgür bırakır. Bu yöntem, boş alanlarda aramaya rehberlik etmesi ve ayrışım isteğini karşılaması için bu bilgiyi kullanır. Bu boş alan bilgisi, dosya sisteminde zaman fazlalığı oluşturur ve bir buddy yapısı kullanılarak hafızada depolanır.

Ertelenen ayrışımın performans faydaları çok açıktır, ve bölüm 7'de bu görülebilir. Önceki bir çalışmada da[3], %30 bir gelişme olduğunu ve birleştirilen iki özellikle CPU kullanımında işlem hacminin %50 azalmasını gözlemledik. Genelde, ertelenen ve çeşitli blok yerleşimleri büyük giriş-çıkışlı sistemlerde dosya sisteminin performansını arttırır.

Parçalara ayrılmayı azaltmak için ertelenen ve çeşitli blok yerleşimlerinin üstünde inşa edilen iki diğer özellik vardır:

    * Çekirdek içi ön yerleşim: Çekirdek içini kullanmak, alan bilgisini özgür bırakır, çekirdek içinde blok ön yerleşim alanı daha güçlü inşa edilebilir. Bu daha fazla, blok yerleştirmesini geliştirir, yazma işlemi yükünü azaltır. Bir inode, ön yerleşim yapılmış bloklar içinde belli öneme sahip olarak indekslenmiş büyük parçalardan birkaçına sahip olabilir. Bu gelişme, HPC uygulamalarına, birkaç node un bir büyük dosyaya farklı offset lerde yazılması operasyonunda, yardımcı olabilir.
    * Yer grupları: bireysel dosya için yerleşim biçiminin kararları bağımsız olarak yapılır. Eğer yerleşimi yapan yapı (allocator) içinde dosya ilişkisinin bilgisi varsa, allocator ilgili dosyaların bir arada yerleşmesini sağlayabilir, buda okuma performansını artırır . Yer grupları özelliği verilen bir nitelik ile dosyaları kümeler. Örneğin SID veya SID kombinasyonlarından oluşan yapılar ve ana dizin. Ertelenen sayfa akışı esnasında, kullanılmış sayfalar gruplar halinde yazılır. Yerleştirilmemiş blokların sayısı, grup-düzeyinde, allocator tarafından bütün bir grup için yeterli boşluk bulunursa , bu alan rezerve edilir. Bu boşluk, grup içindeki dosyaların bireysel olarak yerleşimi için kullanılır.Bu yolda, ilgili dosyalar, bir arada tutulur.

 Özetle, ext4, verimli bir şekilde büyük giriş-çıkış bloğunu tutabilen güçlü bir blok ayrışım planına sahip olacak ve çoklu-ipliğe dizilen iş yüklerinin altındaki küçük dosyalarla dosya sisteminin parçalara ayrılmasını azaltacak.

3.3. Birleştirme

Bu bölümdeki özellikler, parçalara ayırılmadan kaçınılması için blok yerleşimini geliştirme üzerine kurulu olsa da, zamanla dosya sisteminin hâlâ parçalara bölünebilir. Ext4 deki birleştirme eklentisi e4defrag, parçalanan dosya sistemini birleştirmeye yönelik geliştirildi. Bu yazılım tek tek dosyaları veya bütün dosya sistemlerini birleştirebilir . Her dosya için, geçici bir inode yaratır, ve geçici inode a komşu olan alanları tekrar yerleştirir. Sonra, sayfa hafızasına orijinal dosya verisini kopyalar, ve geçici inode un bloklarına önceden yazılmış sayfalar aktarılır. Son olarak, blok işaretçilerini geçici inode'dan, orijinal inode'a aktarır.

4. Güvenilirliği arttırmak

Güvenilirlik, ext3'te çok önemlidir, ve onun muazzam popülerliğinin sebeplerinden biridir. Bu şöhreti kaybetmemek için, ext4 geliştiricileri, dosya sisteminin güvenilirliğini sürdürmeye çok gayret gösteriyorlar. Herhangi bir dosya sistemi tasarımcısı için kendi 64 bitlik boyutta alan parçası yapmak kolaydır. Zor olan, boşluğun büyük miktarlarını gerçek dünyada kullanılabilir yapmaktır.

Journaling ve RAID kullanımına rağmen,diskin dosya sisteminde değişmez bir şekilde bozulmalar vardır. Savunmanın ilk çizgisi problemleri buluyor, gelişmiş metadata tasarımı ile problemlerden kaçınılıyor. Çeşitli düzeylerde iç tutarsızlık önleniyor, sağlama (checksumming) işlemiyle kontrol edilerek bütünlük korunuyor.

Dosya sistemleri ile ilgili önemli hususlardan biri de , bozulmanın ardından dosya sisteminin geçerliliğini tekrar kazanma süresidir. Örneğin RAID depolama ortamında iki terabyte fsck taraması 2 ila 4 saat içinde dosyasistemini temizleyebilir. Eğer depolama ortamında fazla sayıda paylaşımlı dosya sistemi blokları var ise, bunları düzeltmek için pahalı geçişler kullanılacağından, bu süre uzayabilir.

Daha önce bahsedildiği gibi yeni birçok eklenti ve özellik ext4 metadata'ya eklendi. Bununla beraber ext4'ün günlük hayatta yaygın kullanımı için birçok değişiklik yapılmaya devam ediliyor.

4.1. Kullanılmamış Inode sayısı ve hızlı e2fsck

 e2fsck de en çok zaman alan operasyon birinci geçişleri kontrol etmek. Bu işlem için, bütün inode tablolarını okumak, onları taramak, geçerli olanları, geçerli olmayanları ve kullanılmayan inode'ları tespit etmek bir de blokların ve inode yerleşim bit haritalarını doğrulayıp güncellemek gerekiyor. Başlatılmamış gruplar ve -yüksek watermark inode tablosu- özelliği geçiş bir deki taramanın büyük bir kısmının güvenli bir biçimde atlanmasını sağlıyor. Bu özellik e2fsck'nin harcadığı zamanı 2 ila 20 kat azalatabilir. Bu azalma da dosyasisteminin ne kadar dolu olduğuna bağlı tabi. Bu özellik mke2fs time dan veya tune2fs kullanarak , -O uninit_groups seçeneğiyle aktive edilebilir.

Bu özellik sayesinde kernel ne kadar kullanılmamış inode olduğunu, her blok grup inode tablosunun sonunda kaydedebilir. Sonuç olarak e2fsck kullanılmamış inode'lar için okuma ve tarama işlemlerini atlayabilir. Kullanılmamış inode sayısının e2fsck tarafından güvenli bir şekilde kullanılabilmesi için grup açıklayıcıya CRC16 checksum e2fsck'ye eklendi. Bu da alanların geçerliliğini kontrol ediyor.

Tipik bir ext4 dosya sisteminde inodeların %1 ila %10 çevresi kullanılır. Ayrıca inode tablosunun başlangıcındaki inodelar için genellikle inode yerleşim ilkesi geçerlidir. Bu sayede, ilk tarama aşamasında büyük sayıda inode'un işlenmesi engellenir ve ilk aşama hızlandırılır. Şu anda kernel, dosyalar silindiğinde kullanılmamış inode sayısını artırmıyor. Bu sayı e2fsck'nin her çalışmasında güncelleniyor. Bu da şu demek, eğer bir blok grubun bir çok inode'u silinmişse e2fsck bir daha başlatıldığında daha verimli çalışacak.


Çevrimdışı fortran

  • Forum Gurusu
  • *****
  • İleti: 1.671
  • Bir insanı sevmekle başlar her şey...
    • get GNU
Ynt: Yeni ext4 Disk Sistemi
« Yanıtla #2 : 26 Nisan 2014, 06:43:26 ös »


 Şekil 5, ext3'te yapılan bir e2fsck için harcanan zamanı gösteriyor. Görüldüğü üzere bu zaman kaç tane inode kullanıldığına bakılmaksızın, dosya sistemindeki inode sayısına bağlı olarak doğrusal artıyor.Yani ext3 te bir e2fsck için harcanan zaman, 2.1 milyon dosyayı kullansanız da, hiç dosya kullanmasanız da aynı. Fakat ext4 te -kullanılmamış yüksek watermark inode- özelliği ile, e2fsck için harcanan zaman sadece kullanılmış inode sayısına bağlı. Görüldüğü gibi fsck ext4'te, ext3 için 100.000 dosyanın kullanıldığı bir dosya sisteminde harcadığı zamanın küçük bir kısmı kadar zaman alıyor.

Kullanılmamış inode sayısına ek olarak mke2fs ve e2fsck sayesinde bir inode bit haritasını yada bir grubun bloğunu başlatılmamış olarak işaretlemek mümkün. Bu da, kernelin ilk kez yerleştirme yaptığında onları okumamasını sağlıyor. Benzer bir şekilde bu bit haritalarını e2fsck de okumuyor. Fakat bu özellik performansın artışındaki büyük etken değil.Daha önemli bir nokta, eğer mke2fs -O lazy_bg opsiyonu verilmişse, mke2fs format zamanı bit haritalarının yada inode tablolarının kopyasını yaratmayacak. Inode tablolarının kopyalarını yaratmak büyük zaman alır. Ayrıca bu işlem büyük dosya sistemlerinde kısa zamanda 'kirli' sayfalar yarattığı için sorun yaratır.

4.2. Sağlama (Checksumming)

ext4'e metadata checksumming eklenmesi, bozulmaların daha kolay saptanmasına yardımcı oluyor. En azından diskten elde ettiğiniz data'ya körü körüne güvenmekten iyi bir yöntem olduğu bir gerçek. Daha önceki bölümde bahsedildiği gibi grup açıklayıcılara zaten checksum özelliği eklenmişti. Checksumming yapılması gereken diğer bir yer ise Journal (günlük). Derin katmanlarda önemli metadata bulunması ve sürekli üzerine yazılması nedeniyle, Journal'ın tabakaları aşındırması veya tesadüfi bozulmalara neden olması yüksek bir ihtimal.

ext4 Journal'ine Checksumming eklenme işi bitti sayılır[7]. Ext4 ve ext3'te her journal işleminin bir header (başlık) bloğu ve bir commit (işlem) bloğu bulunur. Normal bir Journal operasyonu sırasında, header bloğu ve bütün metadata bloklarının hareketi (işlemin ana yapısı) diske yazılmadan commit bloğu diske gönderilmez. Yeni işlem diski modifiye etmeye başlamadan önce bir önceki işlemin commit bloğunun diske gelmesini bekler.

Bu iki aşama sayesinde, eğer commit bloğu ile header bloğunun işlem numarası aynıysa recovery (düzeltme) sürecinde işlem tekrarlanabilir. Eğer eşleşmezlerse Journal recovery sonlanır. Bunlara rağmen, bu işlemin hatalı yürümesine ve dosya sisteminin bozulmasına yol açabilecek senaryolar üretmek mümkün.

Journal checksum'la beraber Journal kodu, header bloğu dahil bütün blokları CRC32 checksum ile kontrol eder ve bu checksum işlemin commit bloğuna yazılır. Eğer Journal recovery zamanında checksum eşleşmezse ,bu bize işlemde bir yada daha fazla metadata'nın bozulduğunu gösterir. Bu durumda bu işlem ve öncekileri iptal edilir. Commit bloğuna bir şey yazılmaz.

Commit bloğunun içindeki Journal Checksum'ı, Journal'e yazılmayan bloklarında taranmasına izin verdiği için, bir daha her işlem için iki aşamaya gerek yoktur. Commit bloğu işlemdeki diğer bloklar ile eşzamanlı yazılabilir.Bu da Journal Checksum yükünü kaldırır ve bir dosya sistemi operasyonunu önemli bir miktarda hızlandırır (%20 [7]). Checksum 'ı yerleştirme bit haritalarına, uzantılara hatta klasörlere eklemek gibi planlar mevcut. Bu tip işlemler Journal Checksum elimizin altında oldukça verimli bir şekilde yapılabilir. Dosya sistemindeki metadata'nın her değiştiğinde checksum'ı hesaplamak yerine (ki bu sürekli değiştirilen yapılar için büyük yük) metadata yi checksum yapılmış journale ekleyip recovery zamanında geçerliliğinden emin olabiliriz. Blokların dosya sistemine ilk yazıldığında metadata'ya özel checksum'ları olabilir.

5. Diğer yeni özellikler

Yeni özellikler ext4'e sürekli eklenmekte. ext4'te görülmesi beklenen iki yeni özellik de nanosaniye timestamp (tarih bilgisi) ve inode uyarlaması. Bu iki yeni özellik, dosya üzerindeki değişikliklerin takibine ve dosya erişim hızlarına dair bilgilere kesinlik katıyor.

ext3'ün timestamp için bir çözümü var. Fakat bugünün yüksek hızlı işlemcileriyle, bir saniyede bir dosyaya birkaç değişiklik yapmak yeterli değil. ext4'te daha büyük inode'lar kullandığımız için nanosaniyelik timestamp çözümü üretmek mümkün. Şekilde 4'te görülen ext4 inode'una atime, mtime , ctime ve ayrıca yeni bir timestamp olan cr-time (dosya yaratmak için harcanan zaman) için yüksek 32 bitlik alan eklenicek. Nanosaniye alanını göstermek için 30 bit yeterli, 2 bitte dönemi 272 yıl uzatmak için.

NFSv4 istemcileri (client) sunucu (server) tarafında dosyaya yapılan güncellemeleri saptamalı. Bu, istemcileri güncel tutmak için şart. Ctime için nanosaniye destek bulunsa bile, timestamp nanosaniye düzeyinde güncellenmek zorunda değil. İşte ext4 inode uyarlaması özelliği bu sorunu, her inode'a global 64 bitlik sayaçlar ekleyerek çözümlüyor. Bu sayaç dosya her değiştiğinde bir artıyor. Sayacın verilerini kontrol ederek, dosyanın güncellenip güncellenmediğini görmek elimizde. Sayaç dosya yaratırken sıfırlanıyor. Ayrıca sayaç fazlası önemli bir sorun değil, çünkü sadece eşitlik kontrol ediliyor. Inode yorumlama 128 bitlik inode'larda zaten mevcut, düşük 32 bitlerde kullanılıyor ve ext4 inode una yüksek 32 bitlik bir alan eklendi.

6.Taşıma Araçları (Migration Tools)

ext3 geliştiricileri ext3 ve ext2 uyumluluğu ve kullanıcıların karekteristik istekleri üzerinde çalıştılar. ext4, ext3 ile uyumluluğunu sürdürmeye çalışsa bile, disk plânlarının uyuşmaması kaçınılmaz bir gerçek. Bu değişikliklere rağmen kullanıcıların hâlâ dosya sistemlerini ext3'ten ext4'e güncellemeleri mümkün. Ext4'ün yeni özelliklerini hemen kullanabilmeleri ya da dosya sistemlerini herhangi bir yedek almaya ihtiyaç duymaksızın ext4'e çevirmeleri için araçlar mevcut.

6.1. ext3 den ext4'e yükseltme

ext3 kullanıcılarının, yedekleme ve taşıma yapmaya gerek duymadan, bazı ext4 özelliklerini, kullanmaya başlaması için basit bir yükseltme yazılımı bulunmakta. Geçerli ext3 dosya sistemini ext4'e geçirirken hiçbir dosya, yeni özellikler kullanılarak oluşturulmayacak, eski dosyaların hâlâ dolaylı olarak blok haritalamada olması ve böyle yorumlanmasına rağmen. Inode da bir işaretçi, iki formatı ayırır ve ikisine de ext4 dosya sisteminde çalışma izni verir. Tüm yeni ext4 özellikleri -preallocation ve çoklu blok dağıtım gibi- kullanılabilir hâle gelir.

Ayrıca bir araç dosya sistemlerinin ext3'ten ext4'e geçişine olanak sağlayacak. Bu geçiş aracı iki iş gerçekleştirecek: dolaylı'dan kapsamlı haritalamaya geçiş ve inode'ları 256 byte'a genişletmek.

Kapsamsal taşıma (extents migration): ilk adım çevrimiçi yapılmalı ve defragmentation araçları kullanılmalı. Defragmentation ilerleyişi sürecinde dosyalar kapsamsal haritalanmaya çevirilir. Bu yolla dosyalar hem extents'e dönüştürülür hemde defragment edilir.

Inode taşıma (inodes migration): inode yapısının genişletilmesi çevrimdışı yapılmalı. Veri yedeklenip ve asıl dosya sistemi taranır, kapsamsal haritalamaya ve geniş inode'lara çevirilir.

ext4'e geçmeye hazır olmayan fakat gelecekte geçebilecek olan kullanıcılar için, ext3 dosya sistemlerini şimdiden hazırlamak da mümkün. Eğer ext3 dosya sistemi, inode yapısı 256 byte veya daha fazla alan içeren şekilde biçimlendirilmişse, fast extended attribute özelliği hemen kullanılmaya başlanabilir.

6.2. ext4'ten ext3'e alçaltma

ext4'ten ext3'e geri dönüş, ext3'ten ext4'e geçiş kadar doğrudan olmasada her kullanıcı için bir yol bulunmakta. Bu durumda kullanıcılar, noextents mount seçeneğiyle dosya sistemlerini remount edecekler. Ayrıca bu kullanıcılar, tüm dosyaları geçici dosyalara kopyalamarı ve bu dosyaları orijinal dosyaların üstünde yeniden adlandırmalıdır. Tüm dosyalar dolaylı olarak blok haritalama formatına geri döndürüldükten sonra incompat extents bayrağı tune2fs kullanılarak temizlenmelidir.

7. Performans Değerlendirilmesi

Ext4'ün performans değerlendirmesini tanınmış 3 dosya sistemi kalite testiyle ext3 ve XFS'le kıyaslayarak yönettik. ext4, kapsam ve ertelenmiş yerleşim özellikleri etkinleştirilmişken test edildi. Ölçüm testleri ext4'teki yeni özelliklerin etkileri değerlendirip göstermek için kullanıldı. Seçilen 3 ölçüm testi FFSB, Postmark, ve IOzone şeklindeydi. FFSB, ext4 ün kapsam özelliklerinin işleyişini, büyük dosya iş yüklerinde düzenleyişi görmek için kullanıldı. Postmark ext4'ün küçük dosya iş yüklerinde ki performansını görmek için kullanıldı. Son olarak IOzone ise -genel olarak- ext4 dosya sisteminin performansını görmek için kullanıldı.

Bu testlerin hepsi ertelenmiş dağıtım yamalarıyla 2.6.21-rc4 çekirdeğinde yapıldı. ext3 ve ext4 testleri için dosya sistemleri writeback modunda, uygun kapsam ve ertelenmiş dağıtım ayarları da ext4'e göre ayarlandı. Geçerli sisteme bağlama (mount) ayarları XFS testi için kullanıldı.

FFSB ve IOzone ölçüm testleri aynı 4 cpu'lu 2.8 ghz Intel® Xeon™ sistemi ve 2GB Ram'li, 68GB Ultra320 SCSI (10000 RPM) Diske sahip sistemlerde yapıldı. Postmark ise 4 cpu'lu Pentium® III 700 MHz, 4 GB RAM ve 9 GB SCSI (7200 RPM) diske sahip sistemlerde yürütüldü. Tüm test sonuçları ham data bilgileriyle ext4 wiki sayfasında görülebilir.

7.1. FFSB Karşılaştırılması

FFSB güçlü bir dosya ölçüm aracıdır ve çok özel iş yükleri içinde ayarlanabilir. Büyük dosyaların oluşturulmasında multithread testi uygulandı. Bu testte 4 iş parçasıyla (process) 24 adet 1-GB dosya yarartıldı ve sıralı yazma işlemleri vurgulandı.



 Şekil 6'dan çıkan sonuçlara göre, işlem hacminde %35 gelişme ve ext4'te ext3'e göre CPU kullanımında %40 azalma görülebilir. Bu performans ilerleyişi ext4 ve XFS arasındaki farkın azalacağını gösterir. Beklenildiği gibi sonuçlar büyüklük ve erteleniş dağıtımı açısından büyük bitişik dosya yaratmasında performansın geliştirildiğini doğrular.

7.2. Postmark Karşılaştırması

Postmark, birçok işlem parçasını aynı anda yürüten bir mail sunucusunu simüle eden oldukça tanınmış bir benchmark uygulamasıdır. Şekil 7'deki grafik ext4 ile %30 veri kazancı olduğunu gösteriyor. Aynı yüzdelik oranlar CPU kullanımında görülmekte, çünkü metadata veriler, içerik olarak çok daha kompakt. Her şey hafızaya yazıldığından veri yazma hızı veri okuma hızından daha yüksektir.



 Bu sonuçlar gösteriyor ki büyük dosyalardaki üstün performans kazancının yanı sıra ext4 daha küçük iş yükü olan dosyalarda da iyi bir seçim.

7.3. IOzone Karşılaştırılması

IOzone, Benchmark testinde disk giriş/çıkış (I/O) yükünü anlayabilmek için sistem sadece 64M ile başlatıldı. Bu test çeşitli dosya ölçülerinde 8 MB kayıtlarla yapıldı. Yazma, tekrar yazma, okuma, tekrar okuma, rastgele yazma ve rastgele okuma işlemleriyle test edildi. Şekil 8, 512 MB ölçülerindeki dosyaların veri sonuçlarını gösteriyor. Genel değerlendirme yapılırsa, özellikle tekrar yazma ve tekrar okuma işlemlerinde ext3 ve ext4 arasında büyük bir ilerleme görülüyor. Bu test ext4'ün yazma işleminde daha iyi olduğunu gösterse de, XFS hâlâ okuma performansında daha iyi.



8. Sonuç

Daha önce belirtildiği gibi yeni ext4 dosya sistemi ext3'e göre birçok yeni özellik ve kolaylıklar getiriyor ve bu durum ext4'ü çeşitli iş yükleri için iyi bir tercih yapmakta. ext4'ün Linux'a getirilmesi için muazzam bir çaba sarfedildi ve projenin tamamlanması için önümüzde yoğun bir yol haritası var. Bir zamanların basit dosya sistemi, ölçeklenirlik, güvenirlilik, performans ve sağlamlıkla beraber büyük ölçekte çalışmaya hazır bir çözüm oldu. Yakında ext3 kullanıcıları, dosya sistemlerini yükseltme şansı bulup, ext ailesinin en yeni neslinin avantajlarından yararlanabilecekler.

TASDİK

Bu makalenin yazarları, performans ölçümü ve analizi, ext4'ün gelişimi ve desteklenmesi konularında yardımlarından dolayı Jean-Noël Cordenner ve Valérie Clément'e teşekkür eder.

ext4'ün desteklenmesi ve ext4'ün Linux içine uygulanmasına yardımlarından dolayı Andrew Morton’a teşekkür ederiz. Ayrıca,dosya sistemini daha iyi düzeye getirmek için sürekli çalışan tüm ext4 geliştiricilerine; özellikle Ted T’so, Stephen Tweedie, Badari Pulavarty,Dave Kleikamp, Eric Sandeen, Amit Arora, Aneesh Veetil ve Takashi Sato'ya da teşekkür ederiz.

Son olarak, tüm ext3 kullanıcılarına dosya sistemlerindeki eksiklikleri paylaştıkları ve bize ext4'ü daha iyi duruma getirmek için ilham vermelerinden ötürü teşekkürler.

YASALLIK

Telif hakkı: 2007 IBM.

Bu çalışma, yazarların bakış açılarını temsil etmektedir. IBM'in konuya bakışını göstermesi anlamına gelmez.

IBM ve IBM logosu Amerika’da ya da diğer ülkelerde bulunan Uluslar arası İş Makineleri Kurumu (International Business Machines Corporation - IBMC)'ndan tescilli bir markadır.

Luster, Dosya Sistemleri Kümesi(CFS)’nden bir markadır.

Linux, Amerika’da ve diğer ülkelerde Linus Torvalds’ın tescilli bir markasıdır.

Diğer şirket, ürün, ve hizmet isimleri, ticari markalar olabilir veya diğerler markaların hizmet markası olabilir.

Bu alanda IBM ürünlerine yapılan referanslar veya hizmetler, IBM'in, onları kendisinde ya da çalıştırdığı bütün ülkelerde uygun tasarladığını imâ etmez.

Bu doküman, "Olduğu gibi", açıklama veya garantiler olmadan sunulmaktadır.

REFERANSLAR

1-) FFSB'nin Sourceforge üzerine projesi
Teknik rapor; http://sourceforge.net/projects/ffsb
2-) IOzone
Teknik rapor; http://www.iozone.org
3-) Mingming Cao, Theodore Y. Ts’o, Badari Pulavarty, Suparna Bhattacharya, Andreas Dilger ve Alex Tomas.
Gelinen durum: Ext3 dosya sisteminde neredeyiz?; Ottawa Linux Sempozyumu, 2005
4-) Jonathan Corbet
Samba4 için hangi dosya sistemi?
Teknik rapor; http://lwn.net/Articles/112566
5-) Jeffrey Katcher
Yeni bir dosya sistemi için kalite testi oluşturma; Teknik rapor; Network Appliances, 2002
6-) Daniel Phillips
Ext2 için bir dizin indeksi; Beşinci Yıllık Linux Gösterimi ve Konferansı, sayfa:173–182, 2001
7-) Vijayan Prabhakaran, Lakshmi N. Bairavasundaram, Nitin Agrawal, Haryadi S.Gunawi, Andrea C. Arpaci-Dusseau, ve Remzi H. Arpaci Dusseau
Iron dosya sistemleri; SOSP’05,sayfa: 206–220, 2005
8-) Stephen Tweedie
Ext3 journalling dosya sistemi; Ottawa Linux Sempozyumu, 2000
9-) Stephen Tweedie ve Theodore Y Ts’o
Linux’e yönelik planlanan ext2/3 dosya sistemi uzantıları; USENIX Yıllık Teknik Konferansı, sayfa:235–244, 2002

cagataycebi.com