FŐOLDAL

KAPCSOLAT

MÉDIAAJÁNLAT


REGISZTRÁCIÓ HÍRLEVÉL
PC-ÁRUHÁZ DRIVERS SZAMITOGEP Antivirus SZAKÜZLET

· Friss (Szoftver)
·  Úmutató az Intel SpeedStep bekapcsolásásához
·  Úmutató a Cool'n'Quiet bekapcsolásásához
·  Windows XP ”Reloaded” - A hivatalos álláspont
·  Peer-to-peer telefonálás egyszerűen
·  Novell Kisvállalati Csomag 6.5
·  Microsoft Office Visio 2003
·  Windows Media
·  Spamek szűrése szabállyal
·  Itt a SUSE LINUX 9.0
·  OpenOffice
·  NetMeeting
·  Shavlik HFNetChk 4.0 – Windowsupdate.com helyett
·  Új email szerver a SuSE-től
·  Novembertől a boltokban a magyar SuSE Linux 7.3
·  COLOBOT
·  Készítsünk honlapot
·  Hány lapra elegendő a festék???
·  Az NTFS 5 filerendszer
·  Idő szinkronizálása Windows 2000 erdőben
·  Bill Gates, mint Napóleon
· Cikkek > Szoftver
· A Windows2000 lemezkezelésének újdonságai
Dátum : 2001-04-02 07:21:05
Szerző : KEEP


Emlékszem, nyeretlen kétévesként (értsd: a fickó még nem látott UNIX-ot) nemigen értettem, mi a baja egyeseknek a DOS-szal. Varázsoltam Norton (később Volkov) Commanderrel, írtam mókás és kevésbé mókás programokat 286 assembly-ben és Turbo C-ben, sőt még az fdisk /mbr kapcsolójáról is hallottam. Egyáltalán, a Primo Basic System és a HT1080Z számítógépek után (ifjabbaknak: mindkettő magyar fejlesztésű számítógép volt anno) egy DOS-szal felszerelt 286-os a lehetőségek kimeríthetetlen tárházának tűnt. Azután találkoztam az OS/2 2.1 verziójával, majd néhány UNIX-szal is, és rá kellett döbbennem, hogy van élet a DOS-on túl is. Sajnos ezt a felismerést nem követhette azonnali és teljes váltás is, tekintettel egyrészt a Magyarországon futó rengeteg DOS-os Clipper alkalmazásra, másrészt pedig a Microsoft „cipelem a hátamon az örökségem mindhalálig” szoftverfejlesztési modelljére. Mostanára eljutottam oda, hogy szinte már belenyugodtam a DOS örökkévalóságába, de azért lelkesen vadászok minden olyan újdonságra, ami (Microsoft környezetben) túlmutat rajta, és lehetőleg nem kompatibilis vele.

Egy ilyen újonság a Windows2000 dinamikus lemezkezelése, ami amellett, hogy teljesíti a nem–kompatibilitás kritériumát, sok olyan tulajdonsággal is bír, ami rendszergazdai szempontból megér némi tanulmányozást. Mielőtt mélyebbre ásnánk a dinamikus lemezkezelésben, először röviden nézzük át, hogyan is működik a dolog DOS (és Win9x) alatt. A DOS 5. verziója volt először képes arra, hogy „akárhány” partíciót kezelni tudjon; ez a gyakorlatban azt jelentette, hogy négy darab elsődleges (primary) partíciót készíthetünk, illetve ha ennél többre van szükségünk, akkor a három elsődleges mellett egy kiterjesztett (extended) partíció is készíthető, benne logikai meghajtókkal. Ez a kiterjesztett partíció egy klasszikus hack, amivel a lemezkezelés korlátait nem törjük át, csak megkerüljük. A hack tulajdonképpen bevált, hiszen hosszú évekre kielégítette a legtöbb felhasználó igényeit a partíciók számát tekintve. Azért az „akárhány” így sem jelent „végtelen”-t, mert mindegyikhez hozzá kell rendelni az angol ABC egy – egy betűjét (figyelem, Microsoft világról van szó!), márpedig így csak 26 betű jöhet szóba, amiből ráadásul az A és B a floppyknak van fenntartva, vagyis marad 24. Jó, Quake-hez ez is bőven sok, de (sajnos?) nem az otthoni felhasználók igényeihez igazodik a legtöbb szoftvergyártó, és egy valamire való fileszerverben könnyen összejöhet 24 darab partíció. A partícionálásnak ráadásul merev szabályai is vannak, amelyek nagyrészt a BIOS implementációjának köszönhetőek – az elsődleges fizikai lemez első szektorának tartalmaznia kell a Master Boot Record –ot (MBR), mert a BIOS bootoláskor ezt olvassa be, és az MBR tartalmát mint végrehajtható kódot próbálja értelmezni. Mivel egy szektor 512 byte méretű, és az MBR csak egy szektort foglalhat el, túl sok minden nem fér el benne. Windows NT és 2000 esetén az MBR-ben található kód az ntldr.exe programot hívja meg (némileg indirekt, lásd alább), ami nem más, mint az NT betöltőrutinja. Microsoft operációs rendszerek esetén az MBR-ben még egy partíciós tábla is szorong, ami maximum négy bejegyzést tartalmazhat, bennük a partíció típusát – FAT32, NTFS, stb - is megadva (512 byte tényleg nem sok), innen a négy partíciós limit. A kiterjesztett partíció trükkje az, hogy neki külön MBR-je van saját partíciós táblával, amire már nem vonatkozik az 512 byte-os korlát. Egy elsődleges partíciót „aktív”-nak kell beállítani a rendszerben, mert az MBR-ben üldögélő kód ezen aktív partíció első szektorának adja át a vezérlést (ez a szektor a Partition Boot Record, PBR), az ntldr.exe pedig innen kerül meghívásra.
Amit láthatjuk, az NT és a Windows2000 megörökölte a DOS-tól a lemezkezelés szabályait, és – ha csak közbe nem lépünk – ezeket követik működés közben is. A Windows 2000 ezt „basic” lemezkezelésnek hívja, amiből rögtön kiderül, hogy tud valami mást is, különben minek kellene a megkülönböztető név? Ez a más az úgynevezett „dynamic” lemezkezelés, amit hosszas töprengés után esetleg „dinamikus”-nak lehetne fordítani. A dinamikus lemezkezelés technikáját a Veritas cég dolgozta ki eredetileg Unix rendszerekre („we DO innovate” –B.G.), majd ültette át Windows NT-re, a Microsoft pedig tőlük licenszelte a Windows2000 számára. Érdekesség, hogy a Veritas egy saját verziójú dinamikus lemezkezelési megoldást is megjelentetett Windows2000 alá Logical Disc Manager néven, ami egy kicsivel többet tud az operációs rendszerrel adott „gyári” verzióhoz képest; erre a kis plusz-ra még visszatérünk.

Az első nagy különbség a basic és a dinamikus lemezkezelés között a lemezinformációk tárolásának helye. Az MBR helyett a dinamikus lemezekről, a rajtuk elhelyezett partíciókról (amiket az új terminológia szerint volume-nak, vagyis kötetnek hívunk) egy, a lemez legvégén elhelyezett 1MB-os adatbázisban tárolódnak az információk (az igazsághoz hozzátartozik az is, hogy az MBR-ben mindenképpen marad egy partíciós tábla bejegyzés azért, hogy a régebbi lemezkezelő programok ne higgyék azt, egy üres lemezzel van dolguk. Ha a lemezen nincs Windows2000 system vagy boot kötet, akkor a partíciós tábla csak egy bejegyzést tartalmaz, ami az egész lemezt egyetlen partícióként tűnteti fel aminek a típusa „LDM” lesz, ha viszont van system vagy boot kötet a lemezen, akkor a valós információk maradnak meg a partíciós táblában – például azért, hogy a Windows 2000 képes legyen boot-olni, mivel az ntldr.exe nem ismeri a dinamikus lemez koncepcióját). Az adatbázis felépítését az 1. ábra szemlélteti.




1.ábra: A dinamikus lemezt leíró adatbázis


Amint látható, az adatbázis négy részből áll: egy fejléc, amit „Private Header” néven tisztelhetünk, egy tartalomjegyzék, a rekordok és végül egy tranzakciós log állomány. A fejléc az 1MB terület elején található, és legfontosabb tartalma a lemez egyedi azonosítója (GUID), egy 128 bites szám. Ilyen információs adatbázis lemezenként van, ennek megfelelően ha a lemezt egy másik gépbe visszük át, a konfigurációs információi nem vesznek el. Ez alapesetben nem nagy fejlesztés, sőt ősidők óta elvárható „feature”, de rögvest rádöbbenünk fontosságára, ha szoftveres RAID rendszert akarunk Windows 2000 alatt létrehozni, illetve mondjuk egy RAID5-ös csíkkészletet akarunk mindenestől átpakolni egyik gépből a másikba. A Windows NT az ilyen fejlett lemezkezelési információkat (pl. mindent a szoftveres RAID-ről) a registryben tárolt, ami viszont az adott NT telepítéshez volt kötve. Vagyis hiába vittük át a paritásos csíkkészletünk (Stripe Set with Parity vagy RAID5) minden lemezét egy másik NT rendszerbe, az nem működött, és ez az összes többi lemezkezelési specialitásra is igaz volt. Azzal, hogy a dinamikus lemezkezelés ezeket az információkat a lemezhez köti, ezt a problémát kiküszöböli. A lemez GUID-jén kívül a fejlécben az is meg van adva, hogy adott lemez milyen lemezcsoporthoz (Disk Group) tartozik. A lemezcsoport fogalma VERITAS-os örökség: az ő eredeti UNIXos (és NT-s és Windows2000-es) rendszerükben lehetőség van lemezcsoportok létrehozására; egy lemezcsoport csak 1db közös adatbázissal bír, nem pedig lemezenként eggyel – eggyel. Mivel erre alapértelmezésben a Windows2000 nem képes, ezért minden lemez egy egyelemű lemezcsoportnak az egyetlen tagja. Végül a fejléc tartalmaz egy mutatót is az adatbázis tartalomjegyzékére. Amint az az 1. ábrán látszik, a fejlécből van egy tartalék másolat is, ami a lemez utolsó szektorán helyezkedik el.

A tartalomjegyzék 16 szektor méretű, és – mily meglepő – az adatbázis jellemzőit adja meg. Maga az adatbázis egy saját fejléccel kezdődik, amiben többek között az szerepel, hogy az adatbázis hány rekordot tartalmaz, illetve hogy a következő új rekord milyen sorszámmal kerülhet bejegyzésre. Egy rekord pontosan 128 byte hosszúságú és négyféle típusú lehet: partíció, lemez, komponens és kötet. A dinamikus lemezkezelésben partíció néven szólítunk minden folytonos lemezterületet, belőlük állnak a lemezek és a komponensek. A lemez típusú rekord egyszerűen magát a fizikai lemezt jellemzi, illetve azt adja meg, hogy melyik lemezcsoportnak a tagja, de ennek a fentebb vázolt okokból nincs különösebb jelentősége mindaddig, amíg be nem szerezzük a VERITAS saját lemezkezelési rendszerét, és neki nem állunk egynél több elemű lemezcsoportokat létrehozni. A komponens rekord egyfajta kapocs egy vagy több partícióbejegyzés és egy kötet rekord között. Egy kötet állhat egyetlen partícióból (simple volume), de készíthetjük több partíció összevonásával (spanned volume, NT-ben ezt volume set-nek hívták) is. Végül a kötet rekord a GUID-ot, a kötet méretét, állapotát és a hozzá tartozó betűjelzést tárolja. A Windows2000 Resource Kit tartalmaz egy DmDiag nevű alkalmazást, amivel a dinamikus lemez leíró adatbázisa és más érdekességek (pl. mount point-ok) jeleníthetőek meg. A 2. ábrán a DmDiag által visszaadott információk idevágó részeit láthatjuk egy „twilight” nevű gépről, amelyben két fizikai lemez van, egy IDE és egy SCSI, mindkettő dinamikus és – az egyszerűség kedvéért – egy–egy partíciót tartalmaznak. Az ábrán az SCSI lemez adatbázisát vágtam ki, a kötet mérete kb. 8.5GB.

...

---------- disk config Harddisk0 ----------

#Config copy 01

#Header nblocks=5808 blksize=128 hdrsize=512
#flags=0x0100 (CLEAN)
#version: 4/10
#timestamp: 126301043080312500
#dgname: TwilightDg0 dgid: a5b83054-eb23-4a63-9a9f-55086c1b50af
#config: tid=0.1050 nvol=2 nplex=2 nsd=2 ndm=2 nda=0
#pending: tid=0.1050 nvol=2 nplex=2 nsd=2 ndm=2 nda=0
#

!--------------- Ez volt a Privát Fejléc -------------------!

#Block 4: flag=0x0000 ref=4 offset=0 frag_size=83
#Block 5: flag=0x0000 ref=2 offset=0 frag_size=70
#Block 6: flag=0x0000 ref=1 offset=0 frag_size=59
#Block 7: flag=0x0000 ref=3 offset=0 frag_size=84
#Block 8: flag=0x0000 ref=10 offset=0 frag_size=59
#Block 10: flag=0x0000 ref=12 offset=0 frag_size=48
#Block 11: flag=0x0000 ref=7 offset=0 frag_size=51
#Block 12: flag=0x0000 ref=8 offset=0 frag_size=48
#Block 13: flag=0x0000 ref=13 offset=0 frag_size=50
#

!---------------- Ez volt a tartalomjegyzék ----------------!

#Record 1: type=0x0034 flags=0x0000 gen_flags=0x0004 size=59
#Blocks: 6
Disk: Disk1 rid=0.1027 updated=0.1037
assoc: diskid=25359fd6-d7c9-44c8-8966-ea647b64b755
flags:

#Record 2: type=0x0835 flags=0x0000 gen_flags=0x0004 size=70
#Blocks: 5
Group: TwilightDg0 rid=0.1025 update=0.1028
id: dgid=a5b83054-eb23-4a63-9a9f-55086c1b50af
diskset: id=00000000-0000-0000-0000-000000000000
copies: nconfig=all nlog=default
minors: >= 0

#Record 3: type=0x0251 flags=0x0000 gen_flags=0x0004 size=84
#Blocks: 7
Volume: Volume1 rid=0.1030 update=0.1037 mountname=E:
info: len=17864217 guid=dac7d630-4a0f-4de2-8062-ac5ae9787b2a
type: parttype=7 usetype=gen
state: state=ACTIVE
policies: read=SELECT
flags: writeback retain-partition

...

!---------------------------- Ezek meg a rekordok ------------------------------------!

2. ábra: a DmDiag információi egy dinamikus lemez adatbázisából

Hála a fentebb vázolt adatbázisnak, a négy elsődleges partíciós limit megszűnt, és dinamikus lemezek esetén még kiterjesztett partíciókkal sem kell bűvészkednünk; tetszőleges számú partíciót előállíthatunk. Némi számolgatással a „tetszőleges” kicsit tovább konkretizálható persze: az adatbázis 1MB-ján nagyjából 8000 rekord helyezhető el, és mivel egy egyszerű kötet (simple volume) három bejegyzést foglal el, ezért az egy lemezen létrehozható kötetek száma 2500 körül lesz. Igaz, az angol ABC továbbra is csak 26 betűs (bár ki tudja, ha vége az antitröszt pernek, itt is elképzelhető talán némi „fejlesztés” a Microsofttól), de immár lehetőségünk van mountolásra is, ami feleslegessé teszi minden lemezdarabka (partíció) betűjelzéssel való ellátását. UNIX ügyekben járatosak itt megengedhetnek egy halvány félmosolyt mondván, nem is emlékeznek már rá, mióta lehet mindenféle UNIX-ban kézzel mountolni (talán mióta egyáltalán merevlemezek léteznek), és lám, a Microsoft 25 év után jutott el idáig (tavaly volt ui. 25 éves a MS). A mount-olást egy filerendszer – technikai újítás teszi lehetővé, az ún. reparse point-ok bevezetése. A reparse point olyan (NTFS partíción levő file-hoz vagy könyvtárhoz csatolt) információ, amelyben a file vagy könyvtár tényleges elérési útjáról találhatunk információt. „Közönséges” file-oknál vagy könyvtáraknál erre az információra nincs szükség (a reparse point tartalma attribútumként tárolódik különben), de ha például bele kívánunk nézni egy olyan könyvtárba, ami alá előzőleg egy partíciót mountoltunk, akkor az e könyvtárbejegyzéshez tartozó reparse point jelzi az I/O managernek, hogy nem egyszerű fileolvasási művelet következik, hanem további vizsgálódásra van szükség. Mount létrehozásához szükség van egy üres könyvtárra (ahová mount-olni fogunk) és a grafikus Disk Manager programra vagy a parancssoros mountvol.exe-re. Sajnos mount-olni csak lokális partíciókat lehet, hálózati meghajtókat nem, legalábbis a gyári reparse point-ok erre nem adnak lehetőséget. Elvileg bárki gyárthat saját reparse point változatokat is, gyakorlatilag persze ehhez alapos Windows 2000 rendszerprogramozási ismeretekre van szükség. A legtöbben valószínűleg az előregyártott készletet fogjuk használni, amelynek egyik tagja a mount. Egy másik reparse point változat a Hierarchical FileSystem (HFS) megvalósítását szolgálja, egy harmadik pedig a soft link-ek készítését teszi lehetővé. Ez utóbbira érdemes néhány szót vesztegetni, bár ez sem egy forradalmi újdonság – UNIX rendszergazdák számára legalábbis. A link arra szolgál, hogy egy filerendszer két pontja között kapcsolatot létesítsünk vele; felfogható egyfajta pointernek is. Ha egy (megintcsak NTFS partíción elhelyezett) file-ra elhelyezünk egy link-et, akkor a file-ot ezen a link-en keresztül is el tudjuk érni, aminek például kényelmi funkciója van: nem kell a file eléréséhez bonyolult elérési utat megjegyeznünk, hanem mondjuk a saját home könyvtérunkban elhelyezett link-et használva is elérhetjük. UNIX-ban (és Windows2000-ben is) két alfaja van, a soft- és a hard link. A kettő között az alapvető különbség az, hogy a hard link-et manipulálva (pl. törölve) az a file is megváltozik amire mutat, míg a soft (vagy symbolic) link-nél ez nincs így. Hard link-et NT-ben is lehetett már készíteni (és persze lehet w2k-ban is) az ln segédprogrammal, ami a Resource Kit POSIX eszközgyűjteményében rejtőzött, a soft link viszont (amit leginkább junction-nek hívnak Microsoft terminológiában) a Windows2000 újdonsága. Na jó, ez utóbbi mondat csak félig volt igaz, mert már az NT is használta ezt a technológiát, de csak egy jól meghatározott helyen: a registry-ben. Mostmár viszont akár mezei felhasználók számára is elérhető – lenne, ha volna olyan eszköz, amivel soft link létrehozható. Gyárilag a Windows2000-ben nincs, de a Resource Kit-en szerencsére van, linkd névre hallgat.

Dióhéjban ezek voltak a Windows2000 legfontosabb lemezkezelési újdonságai. A következő alkalommal az NTFS filerendszert járjuk körül alaposabban, különös tekintettel a kevésbé ismert, és így egyáltalán nem használt tulajdonságaira.


Farkas Zoltán (farkas@wsh.hu)

Források:

1. D.A.Solomon, M.E.Russinovich: Inside Microsoft Windows2000, MSPress, 2000.
2. Windows 2000 Server Resource Kit
3. M.E.Russinovich: Inside Storage Management 1-2, Windows2000 Magazine, 2000 január – február
4. VERITAS Volume Management Products Whitepaper, www.veritas.com 2000.



Warning: require(../forum/centercomments.php) [function.require]: failed to open stream: No such file or directory in /var/www/www.szamitogep.hu/show/read.php on line 95

Warning: require(../forum/centercomments.php) [function.require]: failed to open stream: No such file or directory in /var/www/www.szamitogep.hu/show/read.php on line 95

Fatal error: require() [function.require]: Failed opening required '../forum/centercomments.php' (include_path='.:/usr/share/php/') in /var/www/www.szamitogep.hu/show/read.php on line 95