Errôl a témáról már volt szó virtuális hasábjanik között, a Rendszerprogramozás rovat keretein belűl. Akkor csak elméleti síkon tárgyaltuk, hogy az MS-DOS (általában helytálló a DOS megnevezés is) hogyan is kezeli a háttértárolókat. Most kezdődő rovatunk célja egy olyan program megírása mely MS-DOS 6.22 (és alatta MS-DOS 4.0-ig) alatt képes a floppy olvasási műveleteket akár 10-30-50 %-kal is meggyorsítani.

Ugyanis ki ne BOSSZANKODOTT volna, hogy LASSÚ a DOS hajlékony-lemez olvasása ?

Ennek gyorsítása felettébb komplex probléma, így elôreláthatólag sok számon keresztül foglalkozunk ezzel.
Természetesen elôször az elméleti hátterét vizsgáljuk meg egyáltalán a file-kezelésnek, rajzos algoritmusokat készítek annak megértésére. Majd egy lassú programmal mutatjuk meg, hogy hogyan is dolgozik a lemezekkel a DOS. Végül jóegynéhány menô cache-elési technikát mutatok be ami ténylegesen meggyorsítja az olvasást floppy-ról. De kezdjük az alapoknál:

A BOOT szektor 

A Rendszerprogramozás rovat 3. számában már szóltunk róla, de most újra elmondjuk a ránk vonatkozó részeket. FIGYELEM: közlöm, hogy CSAK FLOPPY-val foglalkozunk, s a cikkek is teljesen e felé orientálódnak, hisz eredeti célkitűzésünk, hogy a floppy-lemez olvasást gyorsítsuk. (Hisz a winchester-en nincs, ill. nem lehet észrevehetôen gyorsítani az MS-DOS & SmartDrive-hoz képest.) Nehogy valaki abba a tévedésbe essen, hogy cache programot írunk floppy-kra. Ez túl snassz lenne a PC-X User-tôl ... Hmmm találjunk ki valami jót ÍRJUK ÚJRA A DOS FILE-KEZELÉSÉT !!!

A boot-sector neve elôször is még a szép ôsidôkbôl származik mikor az OP rendszer betöltôdése addig tartott míg egy kisgyerek nagy nehezen felhúzott egy csizmát ... A boot , mint angol szó csizmát hivatott jelenteni s a hasonlat azt jeleni, hogy az operációs-rendszert úgy, mint csizmát az ember húzza be a gép a memóriába. A boot-sector floppy-k esetén mindig a 0. oldal 0. sáv és 1-ô szektorában helyezkedik el. A boot-sector-nak több jelentôs feladata van:

A boot folyamat során betöltôdik a memória 0000:7C00 címére, s innen az elsô byte-tól kezdve lefuttatódik. Tudjuk, hogy a boot-sector programja adatotkat információkat is hordoz magában az 512 byte hosszú programban. Hogyan is épül fel ez a program ? Lássuk assembly-ben: 
asm
  jmp @BootEntry {jump short, hisz 128 byte-on belül van a kód}
  db  90h {Ez egy nem használt byte, arra tartogatják, ha far jmp lenne szükség ...}
  OEMName     db 'NWDOS7.0'
  Byte_Sector dw 512
  {stb ... a többi adat}
  
  @BootEntry:
  {és itt jön az a mikro-program amely beolvassa az 
   IO.SYS-t INT 13h-al, s RETF-el elindítja !}
end;
Lássunk az elmondottakra egy Pascal típusú rekordot, mely leírja a boot-sector felépítését: 
PBootSecInforms = ^TBootSecInforms;
TBootSecInforms = record
  JMP            : Array[1..3] of Byte;
  OEMName        : Array[1..8] of Char;
  Byte_Sector    : Word;
  Sector_Cluster : Byte;
  ReservedSecs   : Word;
  FATCount       : Byte;    {FATCount * SectorInOneFAT          }
  MaxRootEntries,           {(MaxRootEntries * 32) / Byte_Sector}
  Total_Sector   : Word;    {DataStart = ReservedSecs + FATSize + RootSize}
  MediaDescriptor: Byte;
  SectorInOneFAT,
  Sector_Track,
  Head_Number,
  Hidden_Sector  : Word;    {if partitions > 32M then It's the Lo Word    }
  Hidden_SectorHi: Word;    {if partitions > 32M then used else not used  }
  BIGTotal_Sector: Longint; {if (partitions > 32M) And (Total_Sector = 0) }
  PhisicalDriveNo: Byte;    {   then used else not used                   }
  InfoLevel      : Word;    {Must be 0 ???}
  SerialNumber   : Longint; {In Hex (bin) }
  VolumeLabel    : Array[1..11] of Char; {'NO NAME    ' if none present}
  FileSystemType : Array[1..8] of Char;  {'FAT12   ' or 'FAT16   ')
  TempArray      : Array[1..1024-62] of Byte; {biztonsági tömb}
end;
A boot-sector-ról már eleget tudunk nézzük, a boot-sector után elhelyezkedô egységet a lemezen, ez:

A FAT 

A DOS jellegű (pontosabban vele kompatibilis) operációs rendszerek mindíg FAT-ot használnak, míg más jelentôsen fejlettebb OP rendszerek is megadják a lehetôségét annak, hogy ne saját (pl.: OS/2 HPFS, vagy WinNT NTFS) file-rendszerüket, hanem a régi FAT-ot használhassuk a másik, pl. DOS OP rendszerrel való kompatibilitás megôrzése véget. (Ez akkor áll fent, pl. ha egy WinNT és egy DOS (tehát kettô) OP rendszer van a gépen.) A FAT az egyik legegyszerűbb - s ez által sok hátránnyal rendelkezô - file-tárolási módszer. Ahogy régen azt hitték, hogy 640KB-a minden bele fér úgy, arra sem gondoltak, hogy lehet, hogy több, mint 65535 cluster-e lesz valamikor egy winchester-nek, hisz még a 32 MB-os partíciók is gondot okoztak régen. Ennek szellemiségében megkülönböztetünk FAT12, FAT16 és FAT32-t. A FAT után álló szám jelenti, hogy a FAT-ban milyen módon tárolja az indexeket. 12 bit-en (3/2 byte-on), vagy 16 bit-en (egy word-ön), vagy újabban egy longint-en 32 bit-en. Mi a FAT16 és leginkább a FAT12-vel foglalkozunk, hisz a floppy-k FAT-ja 12 bit-es.

A winchester szektorokból áll. A HDD-t nem szektor szinten kezeli, a DOS hisz akkor a legnagyobb kezelhető egység 512 byte lenne. Így rengeteg helyet kellene arra áldozni, hogy beazonosítsuk a XY file melyik szektorban található. Így a DOS és minden hasonló OP rendszer (nem UNIX alapú !) több szektort nevez ki egy alapegységnek melyet cluster-nek nevezünk. Egy cluster állhat egy szektorból (pl. a floppy-k esetében) de 2, 4, 8, 16, 32, vagy esetleg 64 szektorból is (64-nél több szektorból nem állhat egy cluster MS-DOS 6.22-alatt). Tehát az egés winchester fel van osztva cluster-ekre valahogy így:

Azt tehát látjuk, hogy a cluster-ek (melyek itt 4 szektorból állnak) 2-től kezdôdnek.

A FAT nem más, mint egy táblázat mely megmutatja, hogy a file (tegyük fel, hogy egy sok KB-os, nagy file-ról van szó) egyes részei hol melyik clusterben helyezkednek el a HDD-n.

Tegyük fel, hogy van egy 23 KB-os file-unk. A FAT megmutatja, hogy a 12. cluster üres. Akkor a file elsô 512 byte * 4 = 2048 byte hosszát a 12. cluster-be írja. (512 byte egy szektor hossza, s 4 szektorból áll a példán egy cluster-ünk.) Tehát a 12. cluster-ben van az elsô 2 KB-t. De a 13. cluster már foglalt más file által, így oda nem írhatunk. A DOS megnézi a 14., 15. ... stb. clustert, míg nem talál üreset. S ooops a 54. cluster üres: akkor ide írja a második 2 KB-ot. Azután megnézi, hogy a következô az 55. üres -e ? Ha igen folytatja az 55-be a 3. 2BK-os darab írását, tegyük fel az 55, 56, 57, 58 - 62. clusterek üresek. De még hátramaradt 3 * 2 KB leírása, s akkor keres még 3 üres cluster-t, legyen a 94. cluster-tôl 101-ig szabad így ide bôven el tudja menteni a 3 cluster-nyi adatot. Így a file, igaz több darabban de a HDD-n van.

Tehát így néz ki az XY file-unk elhelyezkedése a HDD-n: (Egy négyzet egy cluster-t jelent. Ahol piros a négyzet ott más file által foglalt a HDD, ahol fehér ott üres, s ahol fekete ott az XY file darabjai találhatóak.)

Látjuk, hogy az elsô cluster a 2-es sorszámot kapja. Azt is, hogy file-unk elsô 2KB-ja a 12. cluster-en található, majd a következô része a file-nak az 54.-tôl a 62. cluster-ig. Az file utolsó darabja, az utolsó 3 cluster a 94-97 cluster-eken található. A leírtak szerint az is látszik, hogy 97-101-ig találhatóak üres cluster-ek, és utaána is elszórva.

Tehát, még a példa elôtt ott tartottunk, hogy mire jó a FAT ? Nos a kérdés megválaszolása most már halogathatatlan számomra ... Tegyük fel azt a kérdést, hogy honnét tudja a DOS, hogy az XY file egyes darabjai mely clustereken helyezkednek el ? Utolsó kérdésemre a válasz: hát a FAT-ból !

Lássuk szép sorjában az XY file beolvasását a memóriába:

Tehát összefoglalhatjuk általánosan érvényes pontokban a tapasztaltakat: Ha valaki nem érti a FAT file-kezelését az olvassa türelmesen akár még 3-4-szer át mert nem bonyolult, csak egy kicsit kell odafigyelni.

Nos (remélhetôleg) tudjuk már a file kezelés módját, de ezeregy dolog van amit mág át kell nézni.

A FAT-ból mára ennyi elég is volt - hisz már nem sok újat lehet mondani - így inkább nézzük a FAT után következô elemet.

A könyvtár struktúra felépítése és a root-directory 

A FAT után helyezkedik el a következô lemez-kezelési egység a fôkönyvtár. A fôkönyvtárban létrehozható file-ok - könyvtárak száma fix, a lemez formázásakor határozza meg a FORMAT program. Azért került fix helyre a FAT után, mert részint a kompatibilitást akarták a DOS 1.0-val megôrizni, és részint így még egy kicsit is ésszerűnek mondható. Nézzük, meg hogy egy általános könyvtár hogyan épül fel. Ez természetesen mind a fôkönyvtárakra, s mind az alább tárgyalt alkönyvtárakra igaz. Lássuk az erre felépített Pascal rekordot: 
PDirectoryEntry = ^TDirectoryEntry;
TDirectoryEntry = record
  FileName : TChar8;
  Extension: TChar3;
  Attribute: Byte;
  Reserved : Array[1..10] of Byte;
  Time,
  Date,
  ClusterNumber: Word;
  FileSize     : Longint;
end;

Valahogy így néz ki a fôkönyvtár elsô pár bejegyzése:
Név
 
Kit
 
Attr
 
Üres
 
Idô
 
Dát.
 
Cluster
 
Hossz
 
AUTOEXEC
 
BAT
 
archive
 
$8B7B
 
$7C23
 
22
 
953
 
CONFIG
 
SYS
 
archive
 
$8B7B
 
$7C23
 
23
 
993
Tudjuk a főkönytárból ered minden könyvtár, nézzünk egy példát lemezre:

Az A:\TXTS nevű könyvtár, mely rengeteg kis rövid text file-t tartalmaz. Ekkor a fôkönyvtárban a TXTS könyvtárhoz az alábbi könyvtárbejegyzés tartozik:
  
Név
 
Kit
 
Attr
 
Üres
 
Idô
 
Dát.
 
Cluster
 
Hossz
 
TXTS
 
directory
 
$8B7B
 
$7C23
 
8
 
0
Tehát látjuk, hogy a 8. cluster-en kezdôdnek a TXTS alkönyvtár bejegyzései, mely a fentiakhez hasonlóan épülnek fel. HA valakinek eddíg nem esett volna le a KÖNYVTÁRAK FILE-ként vannak tárolva ! Tehát a könyvtárbejegyzések egy olyan file-ban vannak tárolva melyek TDirectoryEntry rekord alapján épülnek fel. Sôt aki a magyar nyelvet már szakbarbárságában abszolút nem 'bírja' művelni azoknak mondom, hogy az alkönyvtárak bejegyzései egy File of TDirectoryEntry típusos file-ban vannak eltárolva. Mivel a könyvtár struktúra file-ként van eltárolva, gondolom nem okoz meglepetést, hogy egy alkönyvtár ha több cluster-bôl áll nem csak folytonosan hanem töredezve is elhelyezkedhet a winchester-en. Csak az a ciki, hogy a file-ként eltárolt file-okat nem lehet csak úgy beolvasni, mint egy file-t mert access denied-ot kapunk. (Persze vannak belsô DOS rutinok melyeket meghívhatunk, hogy felettébb rejtelmes dolgokat tudjunk meg, de ezek használata nem vág témába, s szerintem megfeküdné a t. Olvasó gyomrát ...)

Tehát tegyük fel, hogy a fôkönyvtár TXTS alkönytárának bejegyzésébôl kiderült, hogy a 8. cluster-en kezdôdik a TXTS alkönyvtár struktúrája. Beolvassa a DOS a 8. cluster-t, és sorra pl. DIR parancsra írja ki a benne lévô text file-ok nevét, s esetleg a benne lévô egyéb alkönyvtárak nevét. Mivel tudjuk, hogy 123 text file van a könyvtárban és egy sector a floppy-kon általában egy cluster ekkor rádöbbenünk, hogy nem fog egy cluster-ben elférni mind a 123 file bejegyzése, így több cluster kell, s a TXTS alkönyvtár struktúrája - akár egy file - töredezve lehet a floppy-n. 512 egy sector és most egy cluster is. 32 byte egy bejegyzés így ebbôl az adódik, hogy most egy cluster-en 512/32 bejegyzés tárolható egy = 16 bejegyzéssel. Így kiszámoljuk, hogy 8 cluster kell, hogy mind a 123 bejegyzést a TXTS alkönyvtár eltárolhassa. Hogy történik egy teljes DIR parancs a TXT könyvtárra ?

Most már azt is tudjuk hogyan kezeli a DOS a file-okat - könyvtáraket (Melyek persze töredezettek is lehetnek, nem úgy mint a Linux-ban. Wow az egyetlen dolog mely a DOS javára írható. Cikkírói magán vélemény.)

Ezt a cikket a téma kicsit bonyolultabb volta miatt lehet, hogy több átolvasás után lehet csak megérteni. A cikk megértését felettébb segítheti a Norton Utilities DiskEditor-a. FIGYELEM a NU DiskEdit-t programot, csak Read-Only konfigurációban használjuk, nehágy átírja valamit s aztán ciki legyen. (Ezt beállítani a NU DE program. Tool\Configuration\Read-Only ponton lehet beállítani !)

Figyelem, ha valaki nem ért meg sehogy sem a cikkbôl bizonyos részleteket akkor az eMail-ezzen. (Bonyolultabb problémák több embernek való elmagyarázására esetén IRC lehetôség is kínálkozik ... Csak eMail-ezzetek, s megbeszéljük !)

Következô cikkünk a fizikai lemezkezelés megszakításos módjáról, ill. a saját file-kezelés objetum - ill. még nem definiált rekordi alapjairól szólunk.

FIGYELEM: Feltettük a T&T könyvtárba az R4sQFlp.exe programot, mely megmutatja, hogy bizonyos körülmények között a floppy-ról való olvasás sebessége akár 10-30-50%-kal is megnövelhetô.

Bérczi László
eMail:PC-XUser@IDG.HU, Subject: "T & T rovat"
BELA@MI.STUD.PMMFK.JPTE.HU