cachovani jmen pracuje globalne:
hash = fnv_32_buf(cnp->cn_nameptr, cnp->cn_namelen, FNV1_32_INIT);
hash = fnv_32_buf(&dvp->v_id, sizeof(dvp->v_id), hash);
hash se tvori z jmena a id adresare, tj. bez lokality na urovni adresaru a
polozky jsou do cache zaneseny az pri prvnim vyzadani
DIRHASH pracuje jinak
pro "vhodne" velke adresare se vytvori specialni hash table (pouze pro dany
adresar - princip lokality), do ktere se zanesou zaznamy o vsech momentalne
pritomnych souborech v adresari
je zjevne, ze pri urcitych operacich ma pouziti DIRHASH vyhodu - toto lze ovsem
zjistit pouze na urovni konkretniho filesystemu, obecny (VFS) muze tezko
predpokladat nejaka specifika (proto cachuje on-demand a bez lokality)
o vyhodach/nevyhodach tohoto reseni je mozne diskutovat, rozhodne bych si ale
nedovolil odsoudit je jako "zbytecne". mimochodem, pristup "cim vic to zere
pameti tim hur" bych ocekaval od neprilis inteligentniho stredoskolaka, protoze
jedina zbytecna pamet je ta nepouzita. a vzhledem k tomu ze pri nedostatku
pameti se buffery/cache uvolnuji jako prvni (cache se dokonce nemusi ani
synchronizovat) tak vubec nevadi ze se neco "zbytecne cachuje dvakrat"
obecne k serialu musim podotknout, ze se horsi - stava se z nej verejne haneni
FreeBSD a to zcela neakademicky bez argumentu. FreeBSD popisujete VELMI vagne a
tudiz jsou vami vyvozovane zavery (linux je nejlepsi) neprukazne. A obecne jsou
nektere vety dost podivne:
" Nicmene vzhledem k tomu, ze adresar je sekvence dvojic (jmeno souboru,
inoda), je linearni prohledavani adresare v bufferech velmi pomale."
co ma spolecneho to, ze adresar je sekvence dvojic s tim, ze je jejich
vyhledavani v bufferu pomale?
doufam v lepsi priste ;)
"...pristup "cim vic to zere
pameti tim hur" bych ocekaval od neprilis inteligentniho stredoskolaka..."
No dovolte!
I hloupy stredoskolak vi, ze jakykoli hw, ktery neni vyuzit je spatne reseni...
:-D
Jen jsem si nikde tak moc nevsiml, ze se tam tvrdi ze linux je lepsi.
zada se mi, ze duraz je spis na :: jiste rozdily tu jsou :: :: a projevuje se to...::
jinak velmi zajimava reakce, bude kontra od aoutora clanu?
PJ
Myslim, ze autor nemusi odpovedat. Pretoze neologism od linuxu presiel na freebsd a - vid jeho clanky na blackhole.sk - bola by to asi zbytocna debata, pretoze preferuje freebsd (co mu neupieram, ma na to pravo). Autorovi tohoto serialu prajem, aby sa nedal odradit. Je to skutocne dobry serial...
Zda je velký globální hash nebo více lokálních hashů, je jedno (pokud nám nejde o bránění se DoS-útoku založeném na stresování jedné hashové hodnoty, ale to u filesystému nemá význam). Dokonce bych řekl, že globální hashování má v průměrném případě lepší rozložení a méně kolizí --- ale zase v nejhorším případě je globální hashování horší než lokální.
Ten UFS dirhash skutečně pomůže, ale pouze jednou --- při prvním otvírání všech souborů v adresáři se nebude muset pro každý soubor celý adresář prohledávat. Neměřil jsem to, ale řekl bych, že to může ukázát měřitelný výsledek. Podruhé se už bude číst z VFS cache a pak je jedno, zda tam UFS cache je nebo ne.
(a pokud to nebudeš považovat za hanění BSD, tak věz, že Linux má už index na adresářích na disku :)
Co se týče hanění BSD --- toho si moc nejsem vědom, BSD jsem pořádně pohanil jen v kapitole o SMP, a tam si to zaslouží. Třeba zase v dalším díle popíšu snapshoty na FreeBSD 5, což Linux nemá.