Windows Debugging 208

Storage terimi, bir sisteme bagli olan kalici veri depolama aygitlarini kapsar. Kalicidan kastimiz RAM gibi geçici veri tutan medyum olmayanlardir. Söz gelimi güç kaynagi olmadan medyum hala veri tutabiliyorsa, o isletim sisteminin bakis açisindan storagedir. Buna disk kadar floppy ve optik medyumlar da dâhildir.

Disk mantiksal erisim için 512 byte lik sektörlere bölünmüstür. Bilesik sektörlere partisyon denir. Bir diskte birden fazla partisyon olabilir. Partisyona, örnegin aygit sürücüsünün yaptigi abstraksiyondan tek ve bagimsiz nesne olarak erisildiginde volüm denir. Örnegin diskte tek partisyon varsa, buna volüm denilebilir. Birden fazla partisyon oldugunda ve birçok diske bu yapi dagildiginda bu nesneye multipartisyon volümü deriz.
‘Volüm’ veya ‘partisyon’ kavramlarinin kullanilmalarinin farkli bakis açilari ve farkli mantiklari vardir. Partisyonlama esnasinda yaptigimiz bütün islemleri partmgr.sys partisyon yöneticisi ile yapariz. Sonrasinda da partisyonlara yönelik yapilan IO da bunlari ayirt etmeden bu yönetici sorumludur. Örnegin tek diskteki partisyonlari algilayip ve birlestirip ilgili volüm bilgisini volüm yöneticisi volmgr.sys e aktarir. Burada mount manager mountmgr.sys de devreye girer. Kendisi örnegin mountpoint ilskilerinden ve disklere harf atamalarindan sorumludur. Bu bilgileri registry de tutar.
Yani disk islemlerini volume manager, partisyon islemlerini partition manager ve diskler ile ilgili kullanicilara ve aplikasyonlara erisimi mount manager saglamaktadir.

Geçen bölümde IRP den bahsetmistik. Bir IO yu basarili tanimlayabilmek için bütün ilgili sürücülere ihtiyacimiz var demistik. Daha yüksek abstraksiyondan bu nesneye storage stack deriz. S. 646 bireylerini görevleriyle gösteren güzel bir özet grafigi bulabilirsiniz.

Storage kavramini ve temel disk terimlerini tanimladik. Temel modülleri de özetledik. Simdi diskin kendi mantiksal yapilarina bakabiliriz.

MBR diskin ilk sektöründe partisyon ve erisim bilgileri tutulur. Böylece sistem bootunda BIOS buradan isletim sisteminin boot edebilmesi için gerekli kodu okuyup RAM e yükleyebilir. MBR 32bit genisligindedir ve ondan mesela sadece 2TB lik bir disk alanini tanimlayabilir.

Bunun gibi sinirlamalari geçebilmek için Intel EFI, extensible firmware interface standardini gelistirmistir.
Bu 64 bit genisliginde ana kart da uygulanan firmware, diskteki 64 bit genisligindeki yapilari da okuyabilmektedir. Mümkün kildigi partisyon semasi GPT dir.

Volüm yönetimine bakarsak iki tip diskimiz vardir: basic ve dynamic. Sadece GPT (GUID partitioning Table) veya MBR (Master Boot Record) partisyonlama semalarini kullanan diskler basic dir.
Dynamic in farki multipartisyon özelligidir. Yani bir volüm birden fazla disk üzerinde çok partisyondan olusabilir. O zaman basitçe basic diskdeki partisyona dynamic diskde volüm deriz. Bu terimlerin en yaygin kullanilma sekli zaten böyledir. Yalnizca isletim sisteminin nesneler ile çalisma mantigi açisindan bu önemli degildir.
Sürücü açisindan ama önemlidir. Çünkü volümden söz edince sadece bir diskte partisyonu tanimlayan hangi sektörler arasi konum bilgisinin yaninda, ayrica disk bilgisi ve partisyonlar arasi iliski (spanned, mirrored, striped ve RAID5) de ‘’partisyonu’’ tanimlamaktadir. Volmgr.sys sadece basic diskler ile çalisir. Dynamic yapiyi algilayamaz.

Dynamic diskler ile volmgrx.sys çalisir. Bu dynamic disklerde bulunan ve MBR/GPT in üstüne yukarida sözü geçen arti bilgileri diskten okuyabilir. Örnegin iki diskte birer partisyon yaratip bunlari redundancy için mirror lamak istiyoruz. Disk management da diskleri dynamic yapariz ve bu iki partisyonu raid1 yapabiliriz. Ancak her diskte, GPT veya MBR, bu raid bilgisini nasil tutatiriz?

Bilgiler bu tip diskte LDM Database, logical disk manager bölgesinde tutulur. LDM veri tabani her dynamic diskin sonunda 1 MB lik bir alanda tutulur. Bir disk grubuna/multipartisyon volümüne dahil bütün disklerde bu LDM bilgisi aynidir. Volmgr.sys bu bilgiyi okuyamaz, ama volmgrx.sys dynamic yapilar ile çalisabilen bir volüm yöneticisidir.

Bu tarz dynamic partisyonlara soft denilir, çünkü bu bilgiler GPT veya MBR da tutulmaz. MBR ve GPT de tutulan partisyon bilgileri ile olusturulan basit partisyonlara hard denilir.

Yani GPT, MBR, Basic ve Dynamic ayri özelliklerdir. Kesistikleri noktalar bunlardir: GPT diskten boot edebilmek için donanimin EFI özelligi olmalidir. EFI si olmayan sistem boot da GPT diskteki legacy MBR i kullanip boot edemez, ancak boot dan sonra normal erisebilir. Bunu da sadece isletim sistemi 64 bit ise yapabilir. 32 bit isletim sistemi GPT diske erisemez, sadece legacy MBR bölümünü görür.
Dynamic diskden de Windows boot edemez, yani dynamic MBR veya GPT den boot edemez.

Diske mantiksal erisim kavramlarini özetledikten sonra diskin kendi çalisma sekline bakabiliriz.

Diske islem yaparken bir scheduling algoritmasina ihtiyacimiz olur. Yani diske IO umuzu en efektif nasil yapariz konusunda belli bir metodolojiyi uygulamamiz gerekiyor. Bizi sinirlayan diskin kendi yapisidir. Yani disk platter/spindle disklerinden olusur, burada üst üste bir den fazla da olabilir. Bunu okuyabilmek için de bir okuma/yazma kafasi ile disklerin üzerinden geçeriz. Diskin üzerindeki manyetik alanlari kontrol ederek üzerinde kalici veri depolayabiliriz. Bu kafayi diskin üzerinde yönetmenin farkli yollari vardir.

En yaygin kullanilanlardan biri SCAN algoritmasidir. Bu asansör algoritmasi olarak da bilinir. Örnegin asansör hep bir yönde hizmet verir ve ancak istek olmayip karsi yönden bir istek gelirse yönünü degistirir. Yani asansör en üst kata kadar çikarken istekleri tamamlar ve sonra asagiya dogru yön degistirerek isteklere hizmet vermeye devam eder. Ve yine en alt katta yukari dogru yön degistirir vb. Bu davranis elbette istek oldugu sürece devam eder. Asansör bosken ve herhangi bir katta dururken yeni istek geldiginde, asansör istegin oldugu yöne dogru ilerler ve kendi yönünü bu sekilde belirleyebilir.
Bu sekilde SCAN uygulayan diskin okuma/yazma kafasi da hizmet verir. SCAN in özelligi iki yöne dogru da hizmet verebilmesidir, idle iken istek ne taraftaysa o yöne dogru hareket edebilmesi ve istek oldugu sürece sadece diskin iç veya dis kenarlarinda yön degistirmesidir.

Circular, yani C-SCAN de kafa sadece bir yönde ilerler. Kafa diskin dis kenarina vardiginda, yine diskin iç kenarina hareket etikten sonra, içten disariya dogru hizmet vermeye devam eder. Yani isteklere hizmet verirken kafa hep bir yönde hareket eder.

Daha efektif bir çözüm LOOK algoritmasidir. SCAN den tek bir önemli farki vardir: kafa bir yönde hizmet verirken, o yöndeki son hizmetten sonra yine yön degistirebilir. Yani hizmeti devam ettigi süre SCAN gibi illaki en son iç ve dis silindire kadar hareket edip yön degistirmez. Bu açidan SCAN den daha zekidir.

Circular türevi, C-LOOK da bir farka kadar C-SCAN gibidir: yine isteklere sadece içten disa dogru hizmet verilir, ancak bu sadece istekler arasi yapilir. Yani yine kafanin illaki en iç ve dis silindirlere kadar gitmesine gerek yoktur. Kafanin hareketi hep en disa dogru ve en içe dogru bulunan istek lokasyonlari arasinda gerçeklesir.
Windows C-LOOK algoritmasini uygular.

Son olarak da diske baglanma sekillerine ve ihtiyacimiz olan modüllerin listesini tamamlayabiliriz.

SAN ortamlarinda yaygin olarak multipathing uyarlanir . Redundancy, artiklik için bir diske birden fazla yol üzerinden erisebiliyor olabiliriz. Örnegin sunucuda birden fazla HBA kartimiz olabilir, storage controller Aktif/Aktif çalisip istekleri paralel diske gönderip alabiliyordur ve arada da birçok SAN switchi de olabilir. Bu durumda diske olan fiziki baglantimizi kaybetmemiz zorlasmis olur, ama diske giden her path, yol için bir disk görürüz. Yani isletim sistemi ve disk arasinda kaç erisim imkani varsa, o diski disk management da o kadar kez görürüz.

Bu diskleri ayirt edip tek disk görmemizi saglayan device specific module sürücüsü, DSM dir. Ayrica pathlerin durumlarini kontrol edip isletim sistemine bildirmesinden de sorumludur ve bu pathler arasi farkli load balance ve failover ayarlarini da uygulamaktadir. Ilk disk.sys multipath durumunu algilayip gerekli DSM in devreye alinmasindan sorumludur. Bu durumu kendisi mpio.sys de bildirir ve bu örnegin multipath gelen disklerin güç yönetiminden sorumludur.

Mantiksal disk için ve onun her pathi için bir storage stack olusturulur. Sonra DSM hangi stacke ne gönderecegine karar verir. Örnegin load balance policysine göre her stack üzerinden her path için IO yapabilir. Pathler arasi yük dagilimi gerçeklestirmenin baska bir yöntemi yoktur, kisaca her bir path için farkli bir IRP yapisina ihtiyacimiz olur.

Windows Server 2008 den itibaren Microsoft un da kendi generic DSM i vardir: msdsm.sys . Yaygin olarak buna Microsoft multipath denir. Önemli olan nokta bunu mpio.sys ile karistirmamaktir. Mpio.sys path ayirmaz; sadece DSM in kullanabilecegi bir frameworkdür ve DSM ile isletim istemi arasinda aslinda temel disk haberlesmeleri için bir ara yüz sunar.

Multipath de partition manager yine önemli bir rol oynar: diskleri signature lari (MBR) veya GUID leri (GPT) ini kullanarak ID leyip ayirir; ve iki disk ayni bilgiye sahipse birisinin ID sini random degistirir. Bu, isletim sisteminin Disk signature/GUID degistirilmesi uyarladigi tek algoritmadir. Isletim sisteminde bu ID leme özellikle failover cluster için önem tasimaktadir. Cluster disklerini signature/GUID leri ile IDler ve tanir.

Listeyi tamamlamak adina storage stack de yer alan son ve önemli modüller ntfs.sys ve storport.sys dir. Ntfs daha önceki bölümlerden tanidigimiz NT file system sürücüsüdür. Storport isletim sisteminin port aygit sürücüsüdür ve diger üreticilerin miniport sürücülerine bir ara yüz sunar.  Örnegin HBA sürücüleri veya lokal raid sürücüleri genelde storport miniport sürücüleridir. Storport framewrkünden önce scsiport.sys kullanilmaktaydi, ama scsiport sürücüleri artik kalmadi.

Bütün disk islemlerini disk management ile yapabiliriz. Her sürücü, sunucunun lokal raid sürücüsü olsun veya DSM olsun, Windows un Virtual Disk servisinin API lerini kullanarak disk management da çalisabilir ve böylece diskleri için ayri bir arayüz yazmak zorunda kalmaz. Virtual Disk servisi vds.exe de uyarlanir. Örnegin disk management açildiginda vds.exe bütün aygitlarinin kendisine bildirilmesini bekler.

Son olarak bütün storage stackini özetleyecek olursak: Yazilim IO yapmak istediginde bir önceki bölümde özetledigimiz sekilde I/O subsystemini devreye alir. Ve buradan file system sürücüsü ntfs.sys devreye girer. Bunun altinda volume snapshot sürücüsü volsnap.sys çalisir. Altindadir çünkü file system deki bütün degisiklikleri takip eder. Onun altinda volume manager yer alir, volmgr ve volmgrx.sys. Bu üst seviyede artik disklere harf ile erisiriz. Onun altinda partition manager, partmgr.sys i bulabiliriz. Bütün bunlarin altinda classpnp.sys gibi class sürücümüz çalisir. Bu seviyede storage türevine göre aygiti ayiririz (örnegin disk mi, optik sürücü vb.). Class in altinda port/miniport sürücülerimiz çalisir ve onun altinda da artik donanimsal firmware. Peki mpio veya DSM nerede derseniz, bunlar her path için böyle bir stack olustururlar. IRP olarak bakarsak mpio ve DSM HBA sürücüsü gibi Class sürücüsünün altinda ve donanimin üstünde yer alirlar.

BitLocker ve VSS dâhil olmak üzere Windows isletim sisteminin storage yönetiminin bütün özellikleri Windows Internals 5th ed. Chapter 8 ‘Storage Management’ da anlatilmaktadir: https://technet.microsoft.com/en-us/sysinternals/bb963901
Windows Internals 6^th Edition’in ilk bölümü yayinlandi:
https://technet.microsoft.com/en-us/sysinternals/bb963901

Basar Güner
Sr. Support Engineer, Microsoft