On 2.9.2014 8:07, Vilem Kebrt:
splasily se mi nedavno na serveru zalozni disky tak ze ani geom si s tim
neporadi,
nicmene smart nehlasi problem, asi je to ve filesystemu.
No, tak to ti ta "moje" utilita moc nepomuze. Ta provadi proste linearni
precteni vsech datovycy bloku disk. Logickou strukturou (filesystemem)
se nijak nezabyva. Chyby v ni tak uplne mine a skoro jiste nenapravi.
Asi jsem natvrdlej, Dane neni nekde "nakres" jak se to sklada za sebou
napriklad v pripade geomu ? strycek google vyhodi spoustu hlasek, ale
nakres jsem nenasel, stacilo by mi jak jdou ty vrstvy za sebou a v
kterych syscallech se to pohybuje, pak bych treba konecne pochopil
freebsd pristup na fs :)
To jsou DVE otazky, a obe maji tu vlastnost, ze detailni odpoved by byla
radove delsi nez otazka.
Jen jako nastin ...
GEOM je blokove orientovane datove uloziste. Rekneme, ze zobecneny disk.
Vynechame managementovy interface (ten, ktery umoznuje vrstvy
konfigurovat) a soustredme se jen na "provozni" interface - to, pres
ktery behaji data. No a to je dost jednoduche - ma funkce
precti/zapis/smaz blok a dale poskytuje informaci o jmenu, velikosti
bloku a jejich celkovemu poctu.
No a tyhle filtry lze skladat na sebe. Filtr N zada od jednoho nebo vice
spodnich filtru datove bloky a poskytuje je "nad sebe". Rozhrani nahoru
i dolu je stejne. Podl ejake logiky se ten-ktery filtr rozhodne na jaky
pozadavek odpovi kterymi daty, odkud je vezme a zda (a jak) je
modifikuje - no to je prave vlastni funkce toho filtru a u kazdeho je jina.
Priklad trivialniho filtru je filtr, ktery "vyrabi" partition. Ten kdyz
dostane pozadavek na data z bloku N, tak t cislu N pricte offset
odpovidajici pocatku partition, ktere se dotaz tyka a posle pozadavek
dal dolu. V opacnem smeru jen prehodi data na ktera nijak nesaha.
Prikladem slozitejsiho filtru je RAID5 ovladac, ktery se pri prichodu
pzoadavku na blok N rozhodne z jakeho z podrizenych zdroju ten blok
vlastne chce ziskat a pri zpatecni ceste mozna nebude data jen tak
propoustet, protoze mozna bude muset data dopocitavat s pomoci bloku z
paritniho disku (taze aby vratil jeden blok nahoru bud eptorebovat dva
bloku ze dvou podrizenych poskytovatelu).
GEOM je "in-kernel" rozhrani. Jeji rozhrani se do uzivatelskeho prostoru
neprezentuji, krome toho nejsvrchnejsiho. Ten se prezentuje blokovym
zarizenim v /dev, ktere umoznuje taky v podstate jen cteni/zapis bloku,
zjisteni velikosti sektoru a celeho media.
No, a kdyz nam kupicka GEOMu konecne vypropaguje nejaky ten
datove-ulozny prostor, muzeme zacit premyslet jak na na nem budeme psat
- tedy - jaky na nem bude filesystem.
A to je ta druha kratka otazka s potencialne moc dlouhou odpovedi.
Filesystemu je spousta. Neni dokonce ani dano, ze filesystem musi
existovat nad datovym ulozistem o kterem byla rec pred chvili. Takovej
procfs pod sebou nic takovyho nema. nullfs nakonec taky ne a memfs se
odehrava celej v pameti a taky zadny blokovy datovy uloziste nepotrebuje.
Takze FS je proste neco, co smerem "nahoru" poskytuje domluvenou sadu
funkci. Odkud pro ne bere data je jeho vec. Ano, jedna z moznosti je, ze
si je nejakym, pro dany FS specifickym, zpusobem zaznamenava na nejake
datove uloziste. Treba zrovna GEOM.
I filesystem je "in-kernel" zalezitost. Ruzne filesystemy ziji (a to i
soucasne) uvnitr kernelu, ktery jim dela "zastreseni" a propaguje jejich
sluzby ven, k uzivatelskym aplikacim. A to pres radu syscally (tech
"zakladnich" funkci je daleko vic nez u GEOMu).
Bez naroku na uplnost jde o syscally open, read, write, close, creat,
link, unlink, chdir, fchdir, mknod, chmod, chown, chflags, fchflags,
symlink, readlink, readv, writev, fchown, fchmod, rename, mkdir, rmdir,
quotactl, stat, fstat, lstat, getdirentries, undelete, lchown, funkce z
tridy exattr a acl - a urcite i mnohe dalsi.
Teda, ty syscally v podstate patri VFS subsystemu a ten se rozhodne
kteremu FS (pokud vubec nejakemu) konkretni volani doruci. To zalezi
taky na tom, ktereho souboru se dane volani tyka, protoze z toho se
pozna, ktereho FS se tyka.
No, tak ti nevim, jestli je sance, ze jsem to alespon trochu osvetlil ...
Dan
--
FreeBSD mailing list ([email protected])
http://www.freebsd.cz/listserv/listinfo/users-l
