Dokumentace k tar FS

cile:
	Nasim ukolem bylo napsat read-only tar file system pro linux (dale jen tFS). 
TFS je vlastne program, ktery umozni s tar souborem po namountovani zachazet 
jako s filesystemem (FS).Aby to nebylo tak jednoduche ,tak jsme dale meli 
podporovat i prava souboru, hardlinky, symlinky, devices a pojmenovane roury. 
Vzhledem k tomu, ze existuje nekolik formatu  taru, nam bylo cvicicim 
doporuceno, vybrat si pouze jeden format, ktery budeme podporovat (s tim, ze v 
predmetu OS nam nejde o tar, ale o FS). Rozhodli jsme se proto podporovat posix 
tar s nekteryma omezenimi a zaroven rozsirenimi. K tomuto rozhodnuti nas vedl 
fakt, ze tento format je pouzivan aktualni verzi taru v nami pouzivanem linuxu 
(Mandrake 9.0) a necha si predpokladat, ze je pouzivan i vetsinou soucasnych 
modernich linuxu nebot na www.GNU.org je ten samy tar. Tar je naprosto nevhodny 
format pro implementaci FS. Proto jsme se snazili o pokud mozno co nejvetsi
efektivitu (napr. tim, ze cislo inodu je roven cislu bloku, ktery reprezentuje 
dany soubor + 1, takze kdyz zname cislo inodu, tak nemusime zbytecne prochazet 
cely soubor...). Zaroven jsme se snazili nezbirat vic pameti, nez je opravdu 
nezbytne.

co se povedlo x co ne:
	Nas puvodni plan, ze si nekdo prinese libovolny tar soubor, namountuje ho, a 
bude ho moct pouzivat uplne nevysel. Duvodem je jednak to, ze dany soubor nemusi 
byt nutne zabalen posix tarem a jednak to, ze ani v ramci posix taru 
nepodporujeme uplne vsechno. Co presne podporujeme se doctete v casti zabyvajici 
se pouzitim naseho FS (kde jsou uvedeny i konkretni duvody, proc tomu tak je). 
Na druhe strane je nutno rici, ze i kdyz namountujete spatny tar(nebo soubor, 
ktery ani neni tar), tak by nas FS mel vzdy skoncit korektne, tj. melo by se ho 
minimalne podarit odmountovat bez restartu systemu.
Jinak se ovsem nas tFS necha normalne pouzivat(umoznuje vsechny zakladni 
cinnosti od prochazeni adresaru az po mapovani do pameti a spousteni programu, 
ci zachazeni se zarizenimi).

Pouziti:
Vetsinou jako namountovani tar souboru jako loopback zarizeni:
mount -t tarfs soubor.tar /mnt/tar -o loop


format podporovanych souboru:
	jedna se o soubory zabalene pomoci klasickeho tar -cf novy_soubor 
[soubory||adresare], nebo pridane za konec taru pomoci tar -rf k_cemu co. 
Bohuzel i zde jsou nejaka omezeni: balene adresare||soubory musite uvest bez 
cesty (at uz absolutni, nebo relativni),jedinou vyjimku tvori './'. Pokud 
pridavate na konec taru, tak muzete uvest libovolnou cestu, ktera se nachazi v 
jiz zabalenem souboru. Toto vypada na prvni pohled velice restriktivne, ale kdyz 
zvazime, jak se bezne prikaz tar pouziva, tak podporujeme (odhadem) 95% vsech 
bezne zabalenych souboru, ktere nejsou zakomprimovane. Dale, pokud pridate na 
konec taru nejaky soubor, jehoz cesta se v tar souboru nevyskytuje, tak FS bude 
fungovat stejne, jako by jste tam zadny soubor na konec nepridali. Muzete ovsem 
balit i soubory, jejich jmena i s celou cestou jsou delsi nez 250 znaku, coz je 
nase rozsireni oproti klasickemu posix taru.

Soubory, ktere obsahuji ve jmene cestu nepodporujeme z nekolika duvodu. 
Jednoduse receno, jedna se o velike zesloziteni programu (a tim napr. zvyseni 
rizika zavleceni chyb) , aniz by z toho plynul nejaky veliky uzitek. Bezny 
uzivatel totiz dle nas pouzije prikaz tar v pripade, ze potrebuje zabalit nejaky 
adresar i s podsoubory, takze udela "tar -cf adresar.tar adresar". Dalsim 
duvodem je to, ze pokud zabalite soubor i s cestou, tak adresare, ktere jsou v 
te ceste musime podporovat, aniz bychom meli k dispozici jejich hlavicku, coz by 
znamenalo napr. to, ze bychom nemohli pouzivat jako cislo inodu pozici hlavicky 
daneho souboru + 1 (to je potreba kvuli zefektivneni hledani hlavicek). 
Poslednim duvodem je to, ze dany usecase taru jsme neuvazili hned na zacatku a 
jeho implementace by vyzadovala rozsahlou refaktorizaci, ktera by vyrazne 
ohrozila nase vcasne odevzdani semestralky a take to, ze by to vyzadovalo zabrat 
pamet navic, cemuz jsme se chteli vyhnout. 


Programatorska dokumentace: