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 ;)