update/bdflush problem

[Alexandr Malusek]

kurik na reax.cz (Jan Kurik) writes:

> 	Mohli by jste mi prosim nekdo strucne vysvetlit jaky je rozdil
> mezi daty a metadaty ??? Jestli tomu tady dobre rozumim, tak
> metadata jsou neco jako inodes apod., nebo ne ?

Ano. Krome vlastnich uzivatelskych dat je soubor charakterizovan i
urcitymi atributy (delka, vlastnik, pristupova prava, adresy
alokovanych diskovych bloku, ...). Temto udajum se rika metadata.

Tato diskuse je zvlastni tim, ze se diskutuje o necem, o cem bezny
uzivatel Unixu nevi, jak to presne funguje (to je muj pripad, ale
rozhodne to nechci vztahovat na ostatni diskutujici), ale presto
zasila prispevky, aby si vec vyjasnil.

Diskuse probiha ve dvou rovinach:

1. na urovni uzivatele, kteremu nejaky program nabidne moznost
synchronniho, pripadne asynchronniho, zapisu dat, nebo programatora,
ktery si synchronni zapis dat muze zvolit pomoci volani open pri
otevirani souboru (pripadne pozdeji pres fcntl).

2. na urovni vyvojare jadra, ktery rozhoduje, zda pro zapis dat nebo
metadat, ktera se nachazeji v diskove vyrovnavaci pameti, pouzije
synchronni zapis (kdy jadro ceka na dokonceni diskove operace), nebo
asynchronni zapis (kdy jadro neceka na ukonceni diskove operace), nebo
zda pouzije odlozeny zapis, kdy data ve fronte pouze oznaci a
system az nebude mit dost mista ve fronte, nebo se vyvola sync, tato
data na disk zapise.

Diskuse je "dramaticka" prave tim, ze se obe roviny smesuji. Napriklad
Solaris 2.5 (jsou i patche pro 2.4) implementuje tzv. "kernel
asynchronous writes". Pry urychluji nektere databazove operace az o
30% (to cislo berte s rezervou, nejsem si jim zcela jist). Tento typ
asynchronnich zapisu neznamena, ze se data valeji nekde ve fronte 30s,
to proste znamena, ze jadro posila kontroleru disku jeden blok za
druhym, aniz by cekalo na potvrzeni, ze doslo k zapisu. Vlastni zapis
dat si pak organizuje kontroler sam - poradi si muze zmenit, aby
minimalizoval pohyb hlavicek. Tento pristup samozrejme nezajisti zapis
metadat v urcitem poradi, ale u uzivatelskych dat se mi nezda
nebezpecnejsi nez synchronni zapis. Pokud ale jadro posle data
kontroleru pres synchronni zapis, pak kontroler blok zapise, a pak
teprve odblokuje jadro, cimz mu umozni zapis dalsiho bloku. Tak se
skutecne zajisti zapis metadat ve spravnem poradi.

Cele je to jeste komplikovanejsi, protoze SVR4 implementuje mapovani
souboru do pameti, takze o vlastni odkladani dat na disk se stara
spravce virtualni pameti. Klasicka diskova vyrovnavaci pamet
realizovana pomoci klicovanych front se pouziva pouze pro metadata a
podle me neumoznuje specifikovat poradi zapisu bloku. Proto jsem chtel
vedet, jak je realizovan filesystem, ktery zaruci zapis metadat v
urcitem poradi, aniz by pouzival synchronni zapisy. Krome vyse
zmineneho problemu s kontrolerem (ten mozna pujde vyresit pres HW
nepovoleni optimalizace zapisu) by bylo potreba predelat i algoritmy
pro spravu diskovych vyrovnavacich pameti.

Jak uz jsem uvedl - nejsem odbornik, protoze tyto veci nedelam, ani
nesleduji odbornou literaturu. Takze to, co jsem uvedl, muze byt
spatne - klidne me opravte. Jistou predstavu o tom, jak to funguje,
jsem potreboval pro pochopeni, co vlastne lze v pripade "performance
tuningu" Unixu zlepsovat.

Popis teto problematiky lze najit v:
M. Bach: Principy operacniho systemu Unix, Softwarove Aplikace a Systemy
U. Vahalia: Unix Internals, Prentice Hall

S pozdravem,
-- 
Alexandr Malusek (malusek na ujf.cas.cz)
UJF AV CR