Co to je?
Minix je dnes uz (doufam) nepouzivany filesystem. Jeho limity jsou
priserne: Nejde s nim vyrobit disk >64MB, soubor vetsi jak 64MB
(kupodivu), soubor muze mit nazev dlouhy maximalne 14 znaku (30 u
V2), atd. Pri cteni se musi moc seekovat, takze to asi nikdo
nepouziva (maximalne tak na diskety). Stejne si myslim, ze je o nem
dobre neco vedet. Tak se do toho dame. Jo, jeste musim upozornit,
ze budu popisovat V1 (original) minix, ale ten se stejne moc nelisi
od V2...
Vyroba pokusne diskety
neni az zase tak nutne, aby to byla disketa, muze to byt i partition,
nebo cely disk ;). Na nejakou disketu aplikujeme mkfs.minix
"mkfs.minix /dev/fd0 1440". Tim cislem 1440 (pocet bloku) si nejsem
uplne jist,... Potom je dulezite na disketu neco nakopirovat, udelat
nejake adresare... ...atd. Nezapomente na nejaky vetsi soubor (treba
kernel Linuxu), aby bylo videt jak pracuji indirect bloky.
Co je to blok, inoda, superblock,...
Mame tedy disk rozdeleny na bloky, ale to nam nestaci -> potrebujeme
tam jeste nejak ulozit informace o souborech a adresarich. V
(nejen) minixu se nahlizi na soubor i na adresar jako kus dat, ktere
si alokuji urcite misto na disku. Tomu se rika inoda. Pokud je na
disku adresar, vytvori se inoda (ktera ma nasteveno ze je adresar).
Stejne to je i u souboru. Struktura informaci o inode je nasledujici:
Adresare a soubory
Nekolik slov zaverem
Na zacatku disku (konkretne na offsetu 1024) se nachazi superblock.
To je misto, kde jsou zaznamenany vsechny dulezite veci o disku.
Pokud o nej prijdete, prichazite o cely disk
typedef struct {
__u16 s_ninodes; Pocet inod -- vysvetlim pozdeji
__u16 s_nzones; Pocet bloku (oblasti) -- take az za chvili
__u16 s_imap_blocks; Bitmapa alokace inod
__u16 s_zmap_blocks; Bitmapa alokace bloku (oblasti)
__u16 s_firstdatazone; Prvni datovy blok
__u16 s_log_zone_size; Velikost oblasti (1024 bytes)
__u32 s_max_size; Maximalni velikost souboru.
__u16 s_magic; Magicka hodnota 0x137F
__u16 s_state; Stav FS (clean nebo errors)
}MINIX_SUPERBLOCK;
V predchozi strukture byly dva nezname terminy - inode a blok (zona,
oblast). Takze zacneme bloky. Cely disk je rozdelen na mnoho 1024
bytovych casti - to jsou ty bloky. Kazdy blok muze byt bud' allocated
nebo free. Tento stav urcuje stav bitu v ZMAP prislusejici danemu
bloku. Pokud chce kernel alokovat dalsi blok, staci, aby se podival
do ZMAP, nasel free blok a alokoval ho. Takhle nejak vypada superblok na moji
diskete:
nInodes............: 466 nZones............:1400
Imap blocks........: 1 Zmap blocks.......:1
First datazone.....: 19 Log. zone size....:0
FS Magic...........:137f (ok) FS State..........:01 (clean)
typedef struct {
__u16 i_mode; Pristupova prava, typ, ...
__u16 i_uid; User id inody
__u32 i_size; Velikost v bytech
__u32 i_time; Cas posledni modifikace
__u8 i_gid; Cislo skupiny inody
__u8 i_nlinks; Pocet linku
__u16 i_zone[9]; Jake bloky inoda zabira
}MINIX_INODE;
Proc je ale pole i_zone
tak male? Ne, nedeste se, inoda
samozrejme muze zabirat vic nez 9 bloku. Vzhledem k tomu, ze velke
mnozstvi souboru je malych, je v minixu prvnich 7 bloku zapsano primo
v predchazejici strukture, takze se pri cteni souboru nemusi nikam
jinam seekovat. Pokud inoda zabira vic nez 7 zminenych bloku (>7KB),
jsou informace o alokaci ulozeny v tzv. indirect bloku - to je
tabulka bloku (jako i_zone, ale je to cely blok, tedy __u16
i_zone[512]
). Cislo indirect bloku najdeme v i_zone[7] Inoda
jiz tedy muze mit velikost 512+7 bloku == 519KB, coz stale nestaci.
Takze jsou tady tzv. double indirect bloky, ktere ukazuji na indirect
bloky. Dosahli jsme tedy maximalni velikosti 512*512 + 512 + 7
bloku, coz je 256MB (minix ma ale limit 64MB, takze...). Cislo double
indirect bloku je v i_zone[8]. Stejne jako maji bloky bitmapu alokace
(ZMAP), maji to same i inody - IMAP. Takhle vypada inoda kernelu:
Inode uid...............: 0 Inode gid........: 0
Inode links.............: 1 Inode size.......: 1318927 (1289 zones)
A jeho alokace:
20 21 22 23 24 25 26 [27 ] 28
29 30 31 32 33 34 35 36 37 38
39 40 41 42 43 44 45 46 47 48
(...deleted...)
449 450 451 452 453 454 455 456 457 458
459 460 461 462 463 464 465 466 467 468
469 470 471 472 473 474 475 476 477 478
479 480 481 482 483 484 485 486 487 488
489 490 491 492 493 494 495 496 497 498
499 500 501 502 503 504 505 506 507 508
509 510 511 512 513 514 515 516 517 518
519 520 521 522 523 524 525 526 527 528
529 530 531 532 533 534 535 536 537 538
539 *540 * [541 ] 542 543 544 545 546 547 548
549 550 551 552 553 554 555 556 557 558
(...atd...)
Vsimnete si bloku 20-26, ty jsou ulozeny primo v i_zones[9]. Nasleduje
indirect blok (27). Potom je 512 bloku (kus jsem odmaznul, ...). Double
indirect blok je 540, ten odkazuje na jediny indirect blok (vic jich neni
treba).
Rozdil mezi adresarem a souborem je v podstate v jednom bitu
inode.i_mode. Adresar ma samozrejme pevne danou strukturu:
typedef struct{
__u16 inode; Na jakou inodu polozka odkazuje
char name[14]; Jmeno souboru - null terminated (pokud se tam
ta nula vejde)
}MINIX_DIR_ENTRY;
Jak vidite, nejsou tady (narozdil od fat-fs) informace (velikost,
atributy,...) o jednotlivych polozkach. Ty najdete v prislusnych
inodach. Taky je dulezite, aby adresar zacinal magickymi "." a "..",
pokud je nebude root-adresar obsahovat, nepodari se disk namountovat.
No, kdyz jste to docetli az sem, musim vam prozradit, ze tato
skolicka neni zdaleka kompletni, ale nezoufejte, to hlavni tady je.
Chybi tady popis Minix verze 2, linku (nebo jak to sklonovat;) a
mozna jeste neco jineho...