V dnesnom dieli sa pozrieme, ako funguje UFS (UNIX filesystem), ako rozpozname rozne typy suborov a povieme si co-to o tzv. hardlinkach.
Uvod o sucastiach suboru
Vsetky subory pouzivane v Solaris OS su reprezentovane svojim nazvom - filename a zaznamom, ktory sa nazyva inode. Vo vsebecnosti, filename je asociovany s inodom a inod je asociovany s prislusnym datovym blokom (blokmi).
V tomto obrazku si ukazeme asociaciu medzi adresarom, subormi v nom a preprezentaciou tychto suborov.
V generale: adresar samotny neobsahuje ziadne data. Adresar neobsahuje subory. Adresar je "iba" jeden jednoduchy zoznam, ktory obsahuje nazvy suborov, ktore "zhrnuje" a cislo inodu, ktore prislucha danemu fajlu.
Prikazom #ls -lai si vieme vypisat cisla inodov, na ktore odkazuje dany file(name). Cislo inodu sa nachadza v 1. kolonke vypisu.
20:40:23 (21) root@sol10-01:/export/home/schrapnel # ls -lai
total 16
4 drwxr-xr-x 2 schrapnel other 512 Jul 12 20:40 .
2 drwxr-xr-x 4 root root 512 Jul 8 16:48 ..
9 -rw------- 1 schrapnel other 4 Jul 8 16:48 .bash_history
5 -rw-r--r-- 2 schrapnel other 144 Jul 8 16:48 .profile
5 -rw-r--r-- 2 schrapnel other 144 Jul 8 16:48 hardlink_na_profile
6 -rw-r--r-- 1 schrapnel other 136 Jul 8 16:48 local.cshrc
7 -rw-r--r-- 1 schrapnel other 157 Jul 8 16:48 local.login
8 -rw-r--r-- 1 schrapnel other 174 Jul 8 16:48 local.profile
Pozorny citatel si isto vsimol subor, hardlink_na_profile, ktory ma zhodou okolnosti ten isty inode number ako subor .profile. Pozornemu citatelovi necham cas na porozmyslanie, budeme sa tomu venovat dalej :-)
Tu si mozeme pozriet strukturu inodu:
Ako vidime, inod obsahuje dalsie casti, potrebne pre adresaciu miesta pri velmi velkych suboroch. Tzv. direct data blocks su pointery, ktore odkazuju rovno na data blocky. Pocet tychto odkazov je samozrejme obmadzeny. Preto inod obsahuje aj tzv. single indirect data block, ktory odkazuje na dalsi inod, v ktorom sa vyuziju direct data bloky pre adresovanie dalsieho miesta data blockmi. Ak to nestaci, dalsia cast - double indirect data block obsahuje na dalsi inod, ktory odkazuje na inody, ktore pouzivaju dalsie single indirect data bloky atd atd. Sucastna verzia UFS takto pracuje az do triple indirect bloku. Tymto sposobom je mozne zaadresovat maximalne velky subor o velkosti 2^73 bajtov (8 ZiB). Ak to bude niekedy malo, nie je problem do specifikacie UFS pridat quad indirect data block a mame zas na istu dobu vystarano. ;)
Takze si to zhrnme:
File name
Filename je objekt, najcastiejsie pouzity pre pristup a na manipulaciu so suborom. Subor musi obsahovat meno, ktore je asociovane s inodom.
Inod
Inod je objekt, ktory Solaris OS pouziva na zapis informacie o subore. Vo vseobecnosti, inod obsahuje 2 casti. Prva obsahuje informacie o subore, jeho ownerovi, o pravach suboru, jeho velkosti a pod. Druha cast obsahuje pointery na data bloky prisluchajuce obsahu suboru.
Inody su cislovane a kazdy filesystem obsahuje svoj vlastny zoznam inodov. Vzdy, ked je vytvoreny novy subor, zoznam inodov je o tento novy inod doplneny.
Data block
Data block je jednotka diskoveho priestoru urcena na uchovavanie dat. Regulerne subory, adresare a symbolicke linky pouzivaju (odkazuju) na data blocky. Device files (subory zariadeni) nebsahuju data blocky.
Identifikacia typov suborov
Solaris OS podporuje standardny set typov suborov, ake mozme najst v skoro vsetkych UNIXovych OS. Subor ako taky, nam umoznuje ukladat data, pracovat so zariadeniami, resp prevadzkovat nejaku medzi-procesovu komunikaciu. Z mnohych roznych typov suborov, ktore mozme najst v Solaris OS, su tieto 4 najhlavnejsie:
- Standardne, bezne subory
- Adresare
- Symbolicke linky
- Subory zariadeni (device files)
Bezne subory, adresare a symbolicke linky, vsetky tieto typy suborov obsahuju v istom ponimani data. Naopak, device files, ziadne data neobsahuju. Device files nam dovoluju pristupovat k zariadeniam samotnym.
Na zistenie typu suboru, nam velmi posluzi prikaz ls -l
21:24:39 (31) root@sol10-01:/ # cd /etc/
21:24:42 (32) root@sol10-01:/etc # ls -l
total 658
lrwxrwxrwx 1 root root 14 Jul 6 19:20 TIMEZONE -> ./default/init
drwxr-xr-x 6 root other 512 Jul 11 18:32 X11
drwxr-xr-x 2 adm adm 512 Jul 6 19:29 acct
-rw-r--r-- 1 root sys 253 Feb 28 16:00 aggregation.conf
lrwxrwxrwx 1 root root 14 Jul 6 19:54 aliases -> ./mail/aliases
drwxr-xr-x 6 root other 512 Jul 6 19:21 amd64
drwxr-xr-x 7 root bin 512 Jul 6 19:30 apache
drwxr-xr-x 2 root bin 512 Jul 6 19:31 apache2
drwxr-xr-x 2 root other 512 Jul 6 19:31 apoc
-rw-r--r-- 1 root bin 194 Jan 22 2005 auto_home
-rw-r--r-- 1 root bin 248 Jan 22 2005 auto_master
21:26:10 (33) root@sol10-01:/etc # cd /devices/pci\@0\,0/
21:26:38 (34) root@sol10-01:/devices/pci@0,0 # ls -la
total 18
drwxr-xr-x 9 root sys 512 Jul 6 20:08 .
drwxr-xr-x 2 root sys 512 Jul 11 18:31 ..
drwxr-xr-x 2 root sys 512 Jul 6 20:05 display@f
crw------- 1 root root 99, 0 Jul 6 20:08 display@f:text-0
drwxr-xr-x 3 root sys 512 Jul 6 20:05 pci-ide@7,1
drwxr-xr-x 8 root sys 512 Jul 6 20:05 pci1000,30@10
crw------- 1 root sys 169, 0 Jul 12 21:11 pci1000,30@10:devctl
crw------- 1 root sys 169, 1 Jul 12 21:11 pci1000,30@10:scsi
drwxr-xr-x 2 root sys 512 Jul 6 20:05 pci1022,2000@11
crw------- 1 root sys 10, 1 Jul 12 21:11 pci1022,2000@11:pcn0
drwxr-xr-x 2 root sys 512 Jul 6 20:05 pci1022,2000@12
crw------- 1 root sys 10, 2 Jul 12 21:11 pci1022,2000@12:pcn1
drwxr-xr-x 2 root sys 512 Jul 6 20:05 pci1022,2000@13
crw------- 1 root sys 10, 3 Jul 12 21:11 pci1022,2000@13:pcn2
drwxr-xr-x 2 root sys 512 Jul 6 20:05 pci8086,7191@1
crw------- 1 root sys 84, 255 Jul 12 21:11 pci8086,7191@1:devctl
Ako vidime, mame tu celkom peknu zbierku typov suborov. Podla 1. znaku 1. kolonky (ktora nam mimo ineho vypisuje aj prava suboru), si vieme zistit o aky typ suboru ide.
- -
- regulerny subor
- d
- adresar (directory)
- l
- symbolicka linka (link)
- b
- blokovo orientovany device file
- c
- znakovo (character) orientovany device file
Adresar (directory)
Adresar obsahuje informaciu, ktora asociuje nazov suboru s inodom jemu prisluchajucim. Na rozdiel od regulernych suborov, ktore dokazu obsahovat rozne druhy obsahu, adresar dokaze drzat iba nazov-a-inod zoznam.
Regulerny subor
V podstate najrozsirenejsi druh subory pouzity v Solaris OS. Nebudem sa rozpisovat, co vsetko moze obsahovat, isto so subormi pracujete vsetci:-)
Symbolicka linka
Symbolicka linka je subor, ktory odkazuje na iny subor. Podobne ako adresar, obsahuje iba informacie tykajuce sa adresara, symbolicka linka obsahuje iba 1 druh informacie. Cestu k inemu suboru. Pretoze symbolicka linka obsahuje cestu k inemu suboru, moze odkazovat na subory aj na inom filesysteme. Velkost suboru typu symbolicka linka je pocet znakov, ktore obsahuje cesta k suboru, na ktory odkazuje.
21:37:18 (35) root@sol10-01:/devices/pci@0,0 # cd /
21:37:20 (36) root@sol10-01:/ # ls -l bin
lrwxrwxrwx 1 root root 9 Jul 6 19:20 bin -> ./usr/bin
Symbolicke linky mozu odkazovat na regulerne subory, adresare, symbolicke linky a device files. Je mozne pouzit ako absolutne, tak aj relativnu cestu.
21:38:59 (44) root@sol10-01:/a # ls -l
total 0
-rw-r--r-- 1 root root 0 Jul 12 21:38 file1
21:39:01 (45) root@sol10-01:/a # ln -s file1 file2
21:39:06 (46) root@sol10-01:/a # ls -l
total 2
-rw-r--r-- 1 root root 0 Jul 12 21:38 file1
lrwxrwxrwx 1 root root 5 Jul 12 21:39 file2 -> file1
Read a Write operacie na symbolicku linku sa prejavia na subore, na ktory odkazuje.
Device file
Device file nam poskutuje pristup k zariadeniam. Na rozdiel od regulerneho suboru, adresaru, ci symbolickej linky, device files nemaju asociacie na data bloky. Naopak, inod obsahuje 2 cisla, ktore reprezentuju dane zariadenie.
21:43:21 (54) root@sol10-01:/ # cd /devices/pci\@0\,0/
21:43:46 (55) root@sol10-01:/devices/pci@0,0 # ls -la | grep pcn
crw------- 1 root sys 10, 1 Jul 12 21:11 pci1022,2000@11:pcn0
crw------- 1 root sys 10, 2 Jul 12 21:11 pci1022,2000@12:pcn1
crw------- 1 root sys 10, 3 Jul 12 21:11 pci1022,2000@13:pcn2
Ako vidime, mame tu subory typu character device. (znakovo orientovany) rozdiel si popiseme neskor. Dolezite su ale 2 kolonky, ktore su za ownerom a grupou tychto suborov. 10,1; 10,2; 10,3 ... Tieto dve cisla sa nazyvaju major a minor number. Major number je specificky identifikator, ktory nam hovori o tom, aky driver zariadenia je potrebny pre pristup k zariadeniu. (iny pre sietovu kartu, iny pre disk a pod). Minor number je identifikator zariadenia patriaci do skupiny minor numbera. Takze 10tka - major number nam hovori v podstate o type zariadenia a minor (1,2,3 ...) o identifikatore zariadeni rovnakeho typu.
Znakovo orientoany device file (character-special device file)
Oznacenie typu suboru "c" nam hovori o znakovo orientovanom datovom zariadeni. Data ktore citame/zapisujeme na toto zariadenie putuju v data streame.
22:02:44 (95) root@sol10-01:/ # ls -la /dev/rdsk/ | grep c1t0d0s2
lrwxrwxrwx 1 root root 48 Jul 6 19:59 c1t0d0s2 -> ../../devices/pci@0,0/pci1000,30@10/sd@0,0:c,raw
Blokovo orientovany device file (block-special device file)
Oznacenie typu suboru "b" nam jednoznacne hovori o blokovo orientovanom datovom zariadeni. Pre diskove zariadenie, blokovo orientovany pristup nam zabezpeci volania pre IO operacie zalozene na definovanom bloku definovej velkosti. Velkost bloku zavisi od partikularneho zariadenia.
22:02:54 (96) root@sol10-01:/ # ls -la /dev/dsk/ | grep c1t0d0s2
lrwxrwxrwx 1 root root 44 Jul 6 19:59 c1t0d0s2 -> ../../devices/pci@0,0/pci1000,30@10/sd@0,0:c
Aby sme si lepsie objasnili rozdiel medzi blokovo orientovanymi a znakovo orientovanymi - povedzme to - sposobmi pristupu k zariadeniu, trocha zabrdnem do niektorej z buducich kapitol, kde sa budeme venovat sprave diskov v Solaris OS.
Zoberme si samotny disk, na ktorom je filesystem, data, vsetko mozne. Ak budeme zapisovat na disk cez znakovo orientovany device, zapiseme 1. sektor, 2. sektor, 3.sektor - predstavme si zapis na magneticku pasku. V 1 case pristupujeme k 1. informacii.
Ak ale budeme pristupovat k disku cez blokovo orientovane zariadenie, cez IO operaciu sa nacita 1 blok dat (512b), nahodi sa do cache a pracujeme s celym blokom. Pri zapise sa takisto cely blok cez write zapise. Vyhody/nevyhody/podrobnosti v niektorom z buducich clankov.
Pouzitie Hard Linkov
Hard linka je asociacia medzi nazvom suboru a cislom inodu. Hard linka sa nijak nelisi od bezneho suboru. Kazdy jeden subor je hard linka.
Pred chvilou sme si povedali ze adresar obsahuje asociaciu nazov suboru - cislo inodu. Hard linka je tiez takato asociacia, odkazuje nazov suboru na cislo inodu - na ktory uz odkazuje iny nazov suboru.
22:06:10 (102) root@sol10-01:/ # cd /a
22:06:51 (103) root@sol10-01:/a # rm *
22:08:38 (104) root@sol10-01:/a # mkfile 10m file1
22:08:42 (105) root@sol10-01:/a # ls -li
total 20496
338182 -rw------ 1 root root 10485760 Jul 12 22:08 file1
22:08:46 (106) root@sol10-01:/a # ln file1 file2
22:08:51 (107) root@sol10-01:/a # ls -li
total 40992
338182 -rw------- 2 root root 10485760 Jul 12 22:08 file1
338182 -rw------- 2 root root 10485760 Jul 12 22:08 file2
Ako vidime, mame tu 2 subory. file1 a file2. Oba maju svoj nazov a oba nam odkazuju na ten isty inod = ten isty datovy blok. Oba subory su o velkosti 10M. Oba subory zaberaju na disku 10M.
Ak si porovname symbolicku linku a hard linku, mozeme vidiet zopar rozdielov. Symbolicka linka odkazuje na subor. Subor, ktory ma svoje prava, svojho ownera, svoju grupu. Spocitane a podciarknute, symlink ma prava lrwxrwxrwx, cize prava umoznujuce kazdemu vsetko. Samozrejme pri pristupe na symlink narazime na prava suboru, na ktory odkazuje.
Hard linka je v podstate iny nazov pre ten isty suor. Odkazuje sa na ten isty inod, cize pocet inodov sa nezvysuje, pridal sa len dalsi zaznam do listu adresara. Cize, ked zmenime vlastnost 1 suboru, afektuje sa aj druhy subor - hardlinka, pretoze inod je len jeden a ten drzi zaznam o ownerovi, pravach a podobne.
Dalsia vyhoda hardlinkov je, ze ak by som napr. vytvoril ku kazdemu suboru este jednu hardlinku (napr v adresari /backup), zvacsi sa nam pocet inodov ale obsadenie filesystemu nie. Uzivatel moze zmazat svoje subory, nic sa ale nedeje, hardlinky mam stale v backupe a tym padom zarezervovany data block. = neprisiel som o data.
Vytvaranie hard linkov
majme adresar /export/home/schrapnel v ktorom mam svoje data, subor datafile.
10 -rwx------ 1 755 root 1048576 Jul 12 22:24 /export/home/schrapnel/datafile
Mozme si vsimnut relativne nizke cislo inodu (10) je to separatny filesystem a skoro ziadne subory tam niesu = nizke cislo.
Vytvorime k tomuto suboru backup:
22:28:16 (147) root@sol10-01:/export/home/schrapnel # ln datafile datafile_backup
22:28:21 (148) root@sol10-01:/export/home/schrapnel # ls -li | grep datafile
10 -rwx------ 2 755 root 1048576 Jul 12 22:24 datafile
10 -rwx------ 2 755 root 1048576 Jul 12 22:24 datafile_backup
Aby som vam dokazal, ze je to ten a isty file:
22:28:28 (149) root@sol10-01:/export/home/schrapnel # diff datafile datafile_backup
22:29:01 (150) root@sol10-01:/export/home/schrapnel # find . -inum 10
./datafile
./datafile_backup
Program find ma prepinac -inum ktory nam dovoluje hladat subory podla inodov.
Pri dlhom vypise ls -l si takisto mozme vypisat pocet hardlinkov, ktore nam odkazuju na dany datablock (ak =1 - je to regulerny subor, resp jedinecna hardlinka, aj =2 a viac - je zname ze je to dalsia hardlinka)
Mazanie hardlinkov
22:32:02 (157) root@sol10-01:/export/home/schrapnel # ls -l
total 4134
-rwx------ 2 755 root 1048576 Jul 12 22:24 datafile
-rwx------ 2 755 root 1048576 Jul 12 22:24 datafile_backup
-rw-r--r-- 1 schrapnel other 136 Jul 8 16:48 local.cshrc
-rw-r--r-- 1 schrapnel other 157 Jul 8 16:48 local.login
-rw-r--r-- 1 schrapnel other 174 Jul 8 16:48 local.profile
22:32:04 (158) root@sol10-01:/export/home/schrapnel # rm datafile_backup
22:32:06 (159) root@sol10-01:/export/home/schrapnel # ls -l
total 2070
-rwx------ 1 755 root 1048576 Jul 12 22:24 datafile
-rw-r--r-- 1 schrapnel other 136 Jul 8 16:48 local.cshrc
-rw-r--r-- 1 schrapnel other 157 Jul 8 16:48 local.login
-rw-r--r-- 1 schrapnel other 174 Jul 8 16:48 local.profile
22:32:08 (160) root@sol10-01:/export/home/schrapnel #
Ako vidime, po zmazani hardlinku sa nam dekrementoval inode counter z 2 na 1. Miesto sa neuvolnilo ziadne.
V dalsom dieli sa pozrieme na spravu diskov v Solaris OS, fyzicku strukturu disku (sector, track, cylinder, particie - slice-y, name konvenciu podla fyzickeho pripojenia, logicke nazvy (/dev), fyzicke nazvy (/devices) + nejake cachre machre s hardwarom (re-read zariadeni, rekonfiguracny reboot )
Pekny clanok, ale ako je to s hardlinkami? Celkom som nepochopil (alebo len prehliadol). Ked mam file1 (10MB) a vytvorim na neho hardlink file2, na disku budu dokopy zaberat 20MB?
----------
tommyhot@hackingmachine:~$ microsoft &> /dev/null
NIe, hardlink je v podstate iny nazov suboru, ktory odkazuje na ten isty inode. = ten isty datablock. Cize mozes ich mat aj 1000, stale su to tie iste data.
Napr si vsimni pri ls -l kolko hardlinkov ma "tento adresar" "." budu 2. Jeden pre ../tento_adresar a jeden pre "."
Dalsia vyhoda hardlinkov je, ze ak by som napr. vytvoril ku kazdemu suboru este jednu hardlinku (napr v adresari /backup), zvacsi sa nam pocet inodov ale obsadenie filesystemu nie. Uzivatel moze zmazat svoje subory, nic sa ale nedeje, hardlinky mam stale v backupe a tym padom zarezervovany data block. = neprisiel som o data.
A preto su imho hardlinky pre zalohy nevhodne - sice ochrania pred zmazanim suboru, ale nie pred prepisanim. Opravte ma niekto, ak sa mylim a na UFS sa pri zmene robi kopia.
linux-ext3$ echo test > subor-original
linux-ext3$ ln subor-original subor-zaloha
linux-ext3$ ls -al subor-*
-rw-r--r-- 2 matej users 5 2008-07-16 17:20 subor-original
-rw-r--r-- 2 matej users 5 2008-07-16 17:20 subor-zaloha
linux-ext3$ echo bla > subor-original
linux-ext3$ cat subor-zaloha
bla
Jasne, nepisal som ze su odolne voci prepisaniu :-) A jasne ze to nieje plnohodnotna nahrada za backupovacie systemy. Mal som na mysli nestastne zmazanie. Zo specifikacie UFS a hardlinkov je jasne ze sa obsah prepise, ved oba odkazuju na ten isty inod, cize ten isty data block.
1) defakto jediny rozdiel medzi blokovymi a znakovymi zariadeniami je ten, ze znakove zariadenia (mozu, ale nemusia, ani sa to od nich v standardnom rozhrani necaka) podporuju len operaciu rewind (na zaciatok streamu, ak to ma zmysel), kdezto blokove zariadenia podporuju operaciu seek (tiez sice existuje zopar, ktore to nevedia, pretoze to nema zmysel, ale vo vseobecnosti to plati). Bufferovat vstup mozes aj zo znakoveho zariadenia a aj z neho mozes data citat po blokoch (blokujuci read na 512 bytov napr.)
2) vytvorenie / zrusenie hardlinku nemeni pocet i-nodov. ked vytvoris hardlink, vytvori sa v adresari novy zaznam s rovnakym cislom i-nodu, cize ziadny novy i-nod sa nevytvori. clanok si protireci :) z toho vyplyva, ze nikomu inemu nemozes dat na subor s tym istym i-nodom ine prava, ako mas ty. vytvorenie i-nodu inkrementuje pole refcount o 1. pri mazani suboru z adresara sa v i-node refcount pocitadlo dekrementuje a ked dosiahne 0, je dealokovany aj i-nod.
---
Cuchat s nadchou, to je ako sniffovat bez promiscu.
Ah jasne, detajly o hardlinkoch som upravil. Dik za postrehy.
Vyborne popisane, mam len poznamku k uvedeniu: bolo by dobre zdoraznit ze to co popisujes je spolocne pre vsetky unixy, pretoze clovek moze lahko nadobudnut dojem ze si hovoril specificky o Solarise.
Ale mozno by som len mal pozornejsie citat uvod, to by sa mi potom nestalo ze pocas celeho clanku cakam kedy to uz bude ine ako unix a ono to ani nema byt:)
EDIT: este pre slepcov ako ja s lesklym panelom: ten uvodny obrazok ma cierne popisky, co sa proti ciernemu pozadiu vynimaju extremne zle:)
obrazok som opravil, ten zmrd mal transparency background. jo a mas pravdu; Unix File System neni specificky len pre solaris. ;-) Sorry za zmatenie.
skvely clanok, velmi mi pomohol ...dakujem autorovi...dufam ze coskoro budu nasledovat dalsie casti.