Linux trustees - zkusenosti

[Pavel Kankovsky]

On 18 Jun 2003, Cejka Rudolf wrote:

> Pokud si dobre vzpominam, tak z duvodu "alespon minimalni pouzitelnosti"
> je nutne kdesi v /proc nastavit maximalni pocet i-uzlu na hodnotu vetsi,
> nez je nejvetsi predpokladany pocet souboru v jednom adresari, a pak se
> da existovat i se 100000 soubory v jednom adresari na ext[23].

Dostatecny pocet kesovanych i-nodu je potreba v kazdem pripade, at uz
budou soubory rozstrkane po ruznych adresarich nebo nikoli.

V pripade velkeho adresare je ale asi dulezitejsi dcache. V ni se pri
trose stesti casem akumuluji polozky, se kterymi se pracuje, a nebude
potreba prohledavat ten adresar.

Nicmene se obavam, ze zadne kesovani moc nepomuze, kdyz se budou hledat
neexistujici soubory (tedy aspon pokud se nekesuje i negativni informace)
nebo kdyz se budou v adresari provadet zmeny.

> Kdyby nebylo horsich implementaci OS/FS, nemusel by napr. squid delat
> veci, jako je ukladani cache souboru do stromove hierarchie adresaru,
> nebo newsy a jine aplikace spojovat prirozene rozdelena data do
> jedineho souboru s vlastni strukturou...

Nerikal bych hned horsich, dovedu si snadno predstavit situaci, kdy se fs
optimalizovanemu na male soubory zase podlomi kolena, kdyz ma pracovat se
souborem zvicim 10 GB.

Problem je, ze je velmi tezke udelat neco, co bude dobre fungovat ve
vsech situacich. Nejlepsi by bylo, kdyby filesystem prizpusoboval svou
organizaci tomu, k cemu je pouzivan, ale programy mu to samy nereknou
(i kdyby na to bylo API, tak by ho lini programatori pouzivali jen
vyjimecne...moment, fadvise() vlastne mame a pouziva ho nekdo?) a hadat to
za chodu je cerna magie -- navic to ani nemusi jit, napr. pokud se jedna
o kompromis mezi spolehlivosti a rychlosti: napr. tradicni BSD semantika
vyzaduje, aby byly zapisy vsech operaci s adresari provadeny synchronne, 
coz je pekne (jakmile syscall uspesne skonci, tak vime, ze je to
permanentne zapsane), jenze v 9 z 10 pripadu to akorat zdrzuje...a ted
babo rad,  jestli tech 9 pripadu zpomalit, nebo toho jednoho zbyleho
podvest a pak na konferenci nejmenovaneho MTA poslouchat furt dokola
prskani o tom, jak je ten Linux nespolehlivy. :)

> V opacnem pripade, kdy je povolene monozstvi i-uzlu prilis nizke, doba
> techto testu po prekroceni max. i-nodes rostla exponencialne ( !!! :o(

Tak zle to asi nebylo. Podle mne se to jen zvetsilo o multiplikativni
konstantu (vyjadrujici nutnost lezt pro i-nody na disk), akorat ta
konstanta byla HODNE velka. :)
 

On Wed, 18 Jun 2003, Jan Kasprzak wrote:

> 	Ja si myslim ze stromova struktura ve stylu SQUIDu je lepsi, i
> kdyz mas rozumnou implementaci. Pokud ti totiz nezalezi na jmene
> souboru, muze prakticky veskera cinnost s vytvorenim noveho souboru v
> te stromove strukture bezet bez zamykani (nebo presneji bez zahlceni
> (contention) zamku).

Predpokladam, ze je rec o zamcich nekde v jadre resp. implementaci toho
fs. Myslim, ze to zas tak zasadni argument neni, protoze napr. rozumna
implementace adresare pomoci B stromu by mela zamykat jednotlive stranky,
coz v konecnem dusledku bude mit podobny efekt jako vic adresaru, pricemz
kazdy ma vlastni zamek.


--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."