Farklı file system formatlarımız vardır. Bunların çoğunu zaten tanıyorsunuz. Optik medyumlarda CDFS ve UDF yaygın, flash belleklerde ve eski sistemlerde Fat formatları yaygın; ve diskler artık hep Ntfs.


Format
ı ilk belirleyen fiziki medyumun sektör boyutudur. Örneğin eski disklerde bu 512 Byte dır. Bu medyumdaki en küçük adreslenebilen bloktur.

Format da bir üst seviyede sektörleri clusterlara toplayarak kendisini uyarlar. Örneğin diski formatlarken gelen en küçük cluster boyut seçeneği o medyumun sektör boyutudur. Bu yapı maksimum dosya boyutu veya maksimum partisyon boyutunu etkiler.

Örneğin Fat12 adını 12 bitlik cluster tanımlayıcı uzunluğundan alır. Böylece 212 ile 4096 clusterı Fat12 formatı ile tanımlayabiliriz. Yani cluster size 512 Byte ise, maksimum 2MB, cluster size 8KB (fat12 maks) ise 32MB alan kullanabiliriz. Ama unutmayalım ki kullanımın granüller derinliği de değişir. Eski klasik örneğimizde bit txt ye bir karakter yazıp 4KB cluster size lı diske ansi kaydettiğimizde, dosyanın boyutu 1 Byte olsa da diskteki kapladığı alan 4KB olacaktır. Dosyanın özelliklerinden bunu görebilirsiniz.


Ntfs in tanımlayıcı genişliği 64 bit dir, ama limit 32bit genişliğinde verilmiştir. Yani Ntfs in maksimum partisyon boyutu (264 *64KB)=1YB değildir, (232 * 64KB)=256 TB dır. Ancak bunu belirtmişken VSS in limitinin de 64TB olduğunu hatırlatmak gerekebilir. Ve bir formatın Ntfs.sys in MFT, master file table gibi metadataya ihtiyacı olur. Mesela bir Ntfs volümünde $ işareti ile başlayan bütün dosyalar Ntfs in metadosyalarıdır. Ayrıca örneğin hatırlıyorsanız MBR (2TB limit) ve GPT (16EB limit) partisyon şemalarımız vardır. Bu arada yeni ReFS in partisyon boyut limiti 4.7ZB.


Her belleğe belli bir format şeması üzerinden erişim sağlanır. Bu şekilde bellekte işlemler yapıldıkça, zamanla fragmentasyon oluşur. Basit bir örnek olarak, bir dosyayı ilk boş bir diske yazdığımızda bu birçok sektör ve cluster üzerinde yer alır. Bunlar başta bileşiktir ve en iyi okuma/yazma performansını sergiler. Ancak, diskteki dosya sayısı arttıkça, yeni yazılan dosyalar bileşik yazılamamaya başlar. Dosyalar silinir ve boyutları/içerikleri değişebilir. Böylece zaman geçtikçe dosyaların bileşik diske yazılmış olan oranı azalır. Her tür bellekte zamanla üstündeki I/O işlemleri sonucu fragmentasyon artar ve bu temel bir sorundur. Ntfs burada I/O işlemlerin ekstra performansını yavaşlatacak devamlı bir optimizasyon yapmaz. Yani dosyaları hep bileşik tutma gibi I/O işlemlerine overhead iş yükü getirmez. Sadece MFT alanı özel bir alanda tutulur.
MFT de bütün dosya/klasör bilgilerin lokasyonları tutulduğu için buradaki erişimler hızlı olmalıdırlar ve MFT in disk üzerine yayılması ciddi sorun olurdu. Ancak elbette MFT içindeki kayıtlar açısından fragmentasyona uğrar.
Bildiğiniz gibi de dfrgui.exe ile disklerin defragmentasyonunu yapabiliriz.


MFT de o diskteki her dosya için bir 1KB lık mantıksal kayıt satırı mevcuttur. Burada dosyanın/klasörün genel bilgileri ve özellikleri tutulur. Bu bir Data kısmını da içerir. Burada örneğin VCN (virtual cluster numbers) ve LCN (logical cluster numbers) numaraları tutulur. İşte bunlar ile de diskteki asıl veriye erişiriz. LCN, işletim sisteminin diskte başladığı sektörden itibaren clusterları sayarak, verinin kaçıncı cluster da başladığını belirten rakamdır. Var olan konfigürasyona dayanarak da Ntfs bunun diskteki fiziki lokasyonunu belirler.
Örneğin <<wmic partition get BlockSize, StartingOffset>> komutunu girin. Block size fiziki sektör boyutu. StartingOffset de işletim sisteminin diski kaçıncı sektörden itibaren kullanmaya başladığı rakam.
Örneğin bunlar 512 Byte ve 32256 olsunlar. 4KB lik cluster boyutu ile de disk formatlanmış olsun. Verinin başlama lokasyonu da , LCN, 100 olsun. Data nerede? Arkandan başlayalım: 100cü cluster da verinin başladığını biliyoruz. Bir 4KB lık ntfs cluster 8 tane 512Byte lık fiziki disk sektör blokundan oluştuğundan, LCN i 100cü cluster dan 800cü sektöre çevirebiliriz. Disk, partisyon da Ntfs için 32256 cı sektörden başladığından 800+32256, dosyamızın başlangıcını fiziki 33056 cı sektörde bulabiliriz.

VCN de bu verinin içindeki bir lokasyona erişmemizi sağlar. Yani örneğin o dosyanın belli bir bölümüne erişmek istiyorsak, bu offset Ntfs de VCN ile tutulur. Bu da mesela aynı örnekte 200 ise, 1600 sektör yapar ve asıl erişmek istediğimi yer böylece 34656 cı sektör dür. Mi acaba? Olmak zorunda değildir. Neden? Fragmentasyon.


Fragmentasyon dışında manyetik medyumlardaki ikinci büyük sorun ani işlem kesintilerinden oluşabilecek veri kirliliğidir. Kısaca diske işlem yapılırken güç kaybı olursa, işletim sistemi tekrar o disk ile çalıştığında diskte veri kirliliği olmamalıdır. Ntfs de journaling, loglama mekanizmaları bu amaçla çalışmaktadırlar. Yapılan işlemlerin loglanması elbette bir artı overhead iş yükü getirir, ama işler ters giderse de illaki partisyon erişimi kaybedilmez. Log sayesinde veriler düzeltilebilir. Cache e girmiş ama diske flush edilememiş değişiklikler aktarılabilir ve cache eşlenebilir. Catastrophic durumlarda da chkdsk kullanılır.


Bütün dosya sisteminin yapısını taşıyan da file system driver dır. Bu tarz FSD sürücüler kendilerini direk I/O Manager ile kaydederler. FSD leri yerel ve remote tiplerine ayırırız.
Local tanıdığımız cdfs.sys, fastfat.sys ve ntfs gibi sürücülerdir. Basitçe yazılımdan istek gelince yine I/O stackimizi oluştururuz ve FSD burada yer alır.
Remote da network tarafından tanıdığımız client (LANMan redirector, rutinleri sunan port sürücüsü rdbss.sys ve bu rutinleri kullanan miniport sürücüsü mrxsmb.sys (http üzerinden WebDav, mrxdav.sys), Workstation servisi) ve server (LANMan server, srv2.sys, Server servisi) yapısını kullanırız. Bu iki yapı arasında CIFS, common internet file system protokolünü (Windows da SMB, Server Message Block) kullanırız. Makineler arası cache eşlemeyi de distributed cache coherency protokolü, opportunistic locking (oplock) ile sağlarız. Bunun üç türevi var dır.
1. Exclusive dir, yani client örneğin sunucudaki dosyayı açtığında, buna sadece kendisi erişebilir ve cachelemeyi de böylece client tarafında yapabiliriz.
2. Shared dir. Clientlar okumaları cacheleyebilirler ama yazma için bu seviye yeterli değildir, onun için exclusive gerekir.
3. Batch de farklı clientlara aynı anda aynı dosyaya yazma ve okuma erişimi verilir. Buradaki mantık iligili dosyaların örneğin batch file olmalarıdır. Yani her client istek yapıp dosyayı açıp, istediği gibi cache leyip yine kapatabilir.
Aslında bir dördüncü oplock durumu da vardır. O da hiç oplock kullanılmamasıdır. Bu durumda client kendi tarafında cacheleme yapamaz ve bütün değişikleri eriştiği sunucuya aktarır. Açıkçası o zaman clientlar arası aynı anda erişilen dosyalar için kilitler kullanılmaz ve cacheleme eşlemesi server tarafında kendi lokal erişimi gibi yapılır.
Böylece anlayacağımız nokta, ntfs.sys ile lokalde çalışırken uyguladığımız cacheleme eşlemelerini, başka sunucunun diskindeki dosyalara eriştiğimizde de network altyapısı bileşenlerin yardımını kullanarak benzer şekilde uygulayabilmemizdir.

NTFS ve dosya sistemleri ile ilgili bütün bilgileri çok detaylı şekilde Windows Internals 5th ed. chapter 11 ‘File Systems’ da bulabilirsiniz. Yukarıda söz edilmemiş self-healing, compression ve encryption gibi konular detaylı tartışılmaktadırlar:
http://technet.microsoft.com/en-us/sysinternals/bb963901

Başar Güner
Sr. Support Engineer, Microsoft

http://www.microsoft.com/surface/en/us/default.aspx