Windows Debugging 211
Farkli file system formatlarimiz vardir. Bunlarin çogunu zaten taniyorsunuz. Optik medyumlarda CDFS ve UDF yaygin, flash belleklerde ve eski sistemlerde Fat formatlari yaygin; ve diskler artik hep Ntfs.
Formati ilk belirleyen fiziki medyumun sektör boyutudur. Örnegin eski disklerde bu 512 Byte dir. Bu medyumdaki en küçük adreslenebilen bloktur.
Format da bir üst seviyede sektörleri clusterlara toplayarak kendisini uyarlar. Örnegin diski formatlarken gelen en küçük cluster boyut seçenegi o medyumun sektör boyutudur. Bu yapi maksimum dosya boyutu veya maksimum partisyon boyutunu etkiler.
Örnegin Fat12 adini 12 bitlik cluster tanimlayici uzunlugundan alir. Böylece 212 ile 4096 clusteri Fat12 formati ile tanimlayabiliriz. Yani cluster size 512 Byte ise, maksimum 2MB, cluster size 8KB (fat12 maks) ise 32MB alan kullanabiliriz. Ama unutmayalim ki kullanimin granüller derinligi de degisir. Eski klasik örnegimizde bit txt ye bir karakter yazip 4KB cluster size li diske ansi kaydettigimizde, dosyanin boyutu 1 Byte olsa da diskteki kapladigi alan 4KB olacaktir. Dosyanin özelliklerinden bunu görebilirsiniz.
Ntfs in tanimlayici genisligi 64 bit dir, ama limit 32bit genisliginde verilmistir. Yani Ntfs in maksimum partisyon boyutu (264 *64KB)=1YB degildir, (232 * 64KB)=256 TB dir. Ancak bunu belirtmisken VSS in limitinin de 64TB oldugunu hatirlatmak gerekebilir. Ve bir formatin Ntfs.sys in MFT, master file table gibi metadataya ihtiyaci olur. Mesela bir Ntfs volümünde $ isareti ile baslayan bütün dosyalar Ntfs in metadosyalaridir. Ayrica örnegin hatirliyorsaniz MBR (2TB limit) ve GPT (16EB limit) partisyon semalarimiz vardir. Bu arada yeni ReFS in partisyon boyut limiti 4.7ZB.
Her bellege belli bir format semasi üzerinden erisim saglanir. Bu sekilde bellekte islemler yapildikça, zamanla fragmentasyon olusur. Basit bir örnek olarak, bir dosyayi ilk bos bir diske yazdigimizda bu birçok sektör ve cluster üzerinde yer alir. Bunlar basta bilesiktir ve en iyi okuma/yazma performansini sergiler. Ancak, diskteki dosya sayisi arttikça, yeni yazilan dosyalar bilesik yazilamamaya baslar. Dosyalar silinir ve boyutlari/içerikleri degisebilir. Böylece zaman geçtikçe dosyalarin bilesik diske yazilmis olan orani azalir. Her tür bellekte zamanla üstündeki I/O islemleri sonucu fragmentasyon artar ve bu temel bir sorundur. Ntfs burada I/O islemlerin ekstra performansini yavaslatacak devamli bir optimizasyon yapmaz. Yani dosyalari hep bilesik tutma gibi I/O islemlerine overhead is yükü getirmez. Sadece MFT alani özel bir alanda tutulur.
MFT de bütün dosya/klasör bilgilerin lokasyonlari tutuldugu için buradaki erisimler hizli olmalidirlar ve MFT in disk üzerine yayilmasi ciddi sorun olurdu. Ancak elbette MFT içindeki kayitlar açisindan fragmentasyona ugrar.
Bildiginiz gibi de dfrgui.exe ile disklerin defragmentasyonunu yapabiliriz.
MFT de o diskteki her dosya için bir 1KB lik mantiksal kayit satiri mevcuttur. Burada dosyanin/klasörün genel bilgileri ve özellikleri tutulur. Bu bir Data kismini da içerir. Burada örnegin VCN (virtual cluster numbers) ve LCN (logical cluster numbers) numaralari tutulur. Iste bunlar ile de diskteki asil veriye erisiriz. LCN, isletim sisteminin diskte basladigi sektörden itibaren clusterlari sayarak, verinin kaçinci cluster da basladigini belirten rakamdir. Var olan konfigürasyona dayanarak da Ntfs bunun diskteki fiziki lokasyonunu belirler.
Örnegin <<wmic partition get BlockSize, StartingOffset>> komutunu girin. Block size fiziki sektör boyutu. StartingOffset de isletim sisteminin diski kaçinci sektörden itibaren kullanmaya basladigi rakam.
Örnegin bunlar 512 Byte ve 32256 olsunlar. 4KB lik cluster boyutu ile de disk formatlanmis olsun. Verinin baslama lokasyonu da , LCN, 100 olsun. Data nerede? Arkandan baslayalim: 100cü cluster da verinin basladigini biliyoruz. Bir 4KB lik ntfs cluster 8 tane 512Byte lik fiziki disk sektör blokundan olustugundan, LCN i 100cü cluster dan 800cü sektöre çevirebiliriz. Disk, partisyon da Ntfs için 32256 ci sektörden basladigindan 800+32256, dosyamizin baslangicini fiziki 33056 ci sektörde bulabiliriz.
VCN de bu verinin içindeki bir lokasyona erismemizi saglar. Yani örnegin o dosyanin belli bir bölümüne erismek istiyorsak, bu offset Ntfs de VCN ile tutulur. Bu da mesela ayni örnekte 200 ise, 1600 sektör yapar ve asil erismek istedigimi yer böylece 34656 ci sektör dür. Mi acaba? Olmak zorunda degildir. Neden? Fragmentasyon.
Fragmentasyon disinda manyetik medyumlardaki ikinci büyük sorun ani islem kesintilerinden olusabilecek veri kirliligidir. Kisaca diske islem yapilirken güç kaybi olursa, isletim sistemi tekrar o disk ile çalistiginda diskte veri kirliligi olmamalidir. Ntfs de journaling, loglama mekanizmalari bu amaçla çalismaktadirlar. Yapilan islemlerin loglanmasi elbette bir arti overhead is yükü getirir, ama isler ters giderse de illaki partisyon erisimi kaybedilmez. Log sayesinde veriler düzeltilebilir. Cache e girmis ama diske flush edilememis degisiklikler aktarilabilir ve cache eslenebilir. Catastrophic durumlarda da chkdsk kullanilir.
Bütün dosya sisteminin yapisini tasiyan da file system driver dir. Bu tarz FSD sürücüler kendilerini direk I/O Manager ile kaydederler. FSD leri yerel ve remote tiplerine ayiririz.
Local tanidigimiz cdfs.sys, fastfat.sys ve ntfs gibi sürücülerdir. Basitçe yazilimdan istek gelince yine I/O stackimizi olustururuz ve FSD burada yer alir.
Remote da network tarafindan tanidigimiz 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) yapisini kullaniriz. Bu iki yapi arasinda CIFS, common internet file system protokolünü (Windows da SMB, Server Message Block) kullaniriz. Makineler arasi cache eslemeyi de distributed cache coherency protokolü, opportunistic locking (oplock) ile saglariz. Bunun üç türevi var dir.
1. Exclusive dir, yani client örnegin sunucudaki dosyayi açtiginda, buna sadece kendisi erisebilir ve cachelemeyi de böylece client tarafinda yapabiliriz.
2. Shared dir. Clientlar okumalari cacheleyebilirler ama yazma için bu seviye yeterli degildir, onun için exclusive gerekir.
3. Batch de farkli clientlara ayni anda ayni dosyaya yazma ve okuma erisimi verilir. Buradaki mantik iligili dosyalarin örnegin batch file olmalaridir. Yani her client istek yapip dosyayi açip, istedigi gibi cache leyip yine kapatabilir.
Aslinda bir dördüncü oplock durumu da vardir. O da hiç oplock kullanilmamasidir. Bu durumda client kendi tarafinda cacheleme yapamaz ve bütün degisikleri eristigi sunucuya aktarir. Açikçasi o zaman clientlar arasi ayni anda erisilen dosyalar için kilitler kullanilmaz ve cacheleme eslemesi server tarafinda kendi lokal erisimi gibi yapilir.
Böylece anlayacagimiz nokta, ntfs.sys ile lokalde çalisirken uyguladigimiz cacheleme eslemelerini, baska sunucunun diskindeki dosyalara eristigimizde de network altyapisi bilesenlerin yardimini kullanarak benzer sekilde uygulayabilmemizdir.
NTFS ve dosya sistemleri ile ilgili bütün bilgileri çok detayli sekilde Windows Internals 5th ed. chapter 11 ‘File Systems’ da bulabilirsiniz. Yukarida söz edilmemis self-healing, compression ve encryption gibi konular detayli tartisilmaktadirlar:
https://technet.microsoft.com/en-us/sysinternals/bb963901
Basar Güner
Sr. Support Engineer, Microsoft