DTFS - DeskTop FileSystem

DTFS je jak jiz nazev napovida DeskTop FileSystem. Tento filesystem vyvinula firma Programmed Logic Corp. v dobe, kdy 80MB disk byl naprosto beznou soucasti kazdeho PCcka. V teto dobe byl mimo vykonu hlavnim problemem diskspace. A pokud chcete pro svuj oblibeny Unix (=UnixWare,SCO Unix) misto, musite koupit dalsi disk, ... a/nebo disk stavajici komprimovat. Pod DOSem to neni problem, staci si nainstalovat Stackera ci Dblspace a modlit se aby to nespadlo. Jenze co pod Unixem? Tam staci(lo) pouzit DTFS. Hlavni cil tohoto filesystemu je co nejvetsi vyuziti diskove kapacity pro male unixove systemy. Jedna se samozrejme o inode-based fs, jak je v Unixu zvykem. Tento system se ovsem pouziva i dnes, ovsem minimalne. Naleznete jej napriklad v SCO OpenServeru 5, je jim naformatovana /stand partition.

Jak jsem jiz rekl^H^H^H^Hpsal, $SUBJ je klasicky inode-based filesystem. Disk vypada tedy klasicky: Superblock, Block bitmap, Inode bitmap, Data/Inode blocks. Chybi oblast s Inody, ty jsou alokovany automaticky v datove oblasti. Tato vlastnost sice trochu zpomaluje system, ale setri misto na disku a nejste omezovani poctem inod. Kazna inoda,pokud je mensi nez n bloku, obsahuje odkazy na datove bloky. Pokud je vetsi, odkaz vede na tzv. direct blok, ktery obsahuje adresy na datove bloky. Pokud se inoda nevejde ani do tohoto prostoru, obsahuje odkazy na tzv. indirect bloky. Ty obsahuji adresy direct bloku a ty adresy datovych bloku. Vse doufejme vysvetli obrazek:

inoda          1   2   3   4
               |   .   .   |
indirect  1  2  3  4       1  2  3  4
bloky     |  .  .  .       .  |  .  .
          |        |          |
direct    1 2 3 4  1 2 3 4    1 2 3 4
bloky     | | | |  | | | |    | | | |
          | | | |  | | | |    | | | |
data      1 2 3 4  5 6 7 8    9 A B C
bloky

Misto tecek jsou samozrejme dalsi odkazy, jenom se mi to ve vi(1) nechtelo cele kreslit. V tomto se jedna temer standardni Unixovy fs. Pokud do tohoto schema zacneme implementovat kompresi dat, zacina zabava :-) Komprese musi byt samozrejme on-line a musi byt podporovan zapis / cteni z kterehokoliv mista. Komprimovany jsou samozrejme cele bloky. Diky tomu neni komprese tak ucinna, ale random-access cteni je relativne rychle. U kazdeho data bloku je uvedeno, kolik obsahuje DEkomprimovanych bajtu. Tato informace je uvedena i u prislusnych direct/indirect bloku. Pokud chcete nacist par bajtu z nejake pozice, staci projit strom a nalezt blok(y) obsahujici ctena data a dekomprimovat je. Horsi situace nastava, kdyz do prostred souboru chcete neco zapsat a data nelze zkomprimovat tak, aby se vesla do predchozich bloku. Potom musite jeden blok rozdelit na dva a pridat novy blok do stromu. Pokud jiz ve stromu neni misto, je potreba pridat dalsi uroven. To se ale nastesti prilis casto nestava. Diky alokaci novych bloku "uprostred" souboru se casto stava, ze vznikaji prazdne "diry", neobsahujici zadna data. Proto je potreba vytvorit daemonka, ktery se bude starat o presypavani dat a niceni takovychto der.

Z Linuxu si takovyto filesystem nenamountujete, dalsi informace ziskate velmi tezko, nebot se jedna o komercni zalezitost. Altavistou jsem nasel par dokumentu, dohromady jsem se z nich nic zajimaveho nedozvedel.