Zmeny v GEOM / UFS - opozdeny zapis

[Miroslav Lachman]

Dan Lukes wrote:
> Miroslav Lachman wrote:
>> K memu prekvapeni dochazi k tomu, ze `tar xf ports.tgz` dobehne a jeste
>> dalsi dve minuty probihaji zapisy na disk.
>>
>> Vim, ze normalne takhle probihaji Soft Updates, ale tam byval myslim
>> limit do 30 sekund
>
> Pockej pockej. sync/async/softupdates je o zapisu metadat. Nikoliv o
> zapisu samotnych dat (tedy obsahu souboru).

Ja samozrejme nevim, co presne se na disk zapisuje, ja jen z iostat 
vidim, ze se "neco" zapisuje jeste hodne dlouho po tom, co dobehne tar.

> Pozorovana zmena v chovani tak tedy nemusi mit nic spolecneho s nejakou
> zmenou v UFS nebo GEOM, muze jit "pouze" o zmenu tykajici se prace s
> diskovymi buffery, nebo dokonce i jen prosta zmena velikosti tehle bufferu.

Ano, to je v podstate to, na co se ptam - jestli nekdo vi o tom, ze by 
se v celem tom dlouhem retezci zavislosti a udalosti zmenilo neco 
zasadniho, co muze mit na tohle vliv.

>> Aby toho nebylo malo, tak na starem stroji s 8.3 a disky Samsung F1 1TB
>> to rozbaleni ports.tgz trva mene nez minutu, cca 0:55.
>> Na novem Cisco UCS C200 se SATA III radicem a disky Seagate
>> Constellation ES 1TB to trva dvojnasobek casu, cca 1:52
>
> To je, bohuzel, prilis mnoho zmen najednou. Nelze rict, jestli systemu
> "nesedi" nejaka konkretni komponenta noveho systemu, pripadne pro ni ma
> neoptimalne rychle ovladace a jestli by to tam "slo pomalu" i puvodnimu
> systemu, nebo jestli je to opravdu otazka jine verze OS.

Prisel jsem na to ted celkem nahodou, takze jsem zatim nemel moznost to 
zkusit na identickem HW s jinou verzi OS, ale snad na to do konce sveta 
jeste dojde :)
Spis jsem to myslel tak, ze na HW, ktery je po vsech strankach mnohem 
starsi a pomalejsi, probehne stejna "prace" mnohem rychleji, nez na 
novem HW s novym SW.

>> Jeste teda dalsi zmena 9.1 oproti 8.3 je ta, ze se pouziva AHCI a disky
>> jsou jako ada0 a ada1. To uz jsem drive cetl, ze nekdo ma s touhle
>> "novinkou" pomalejsi praci disku, nez se starsim rezimem.
>
> Pouzivam AHCI rutinne uz dlouho - a na 8.3 (myslim, ze uz i na
> predchozich) a zatim jsem zmineny problem nezaznamenal, i kdyz na rade
> stroju neni vykon diskoveho systemu nijak kriticky, takze pokdu tam
> snizeny vykon ve skutecnosti je, tak jsem si nemusel vsimnout.

Ono to urcite neni tak tragicky s tim vykonem. Ja to zkousel nekdy v 
dobach 8.2 a to bylo na identickem HW a SW s AHCI skutecne o neco 
pomalejsi, nez klasicke IDE.
Ale zase je to jen o nejakem konkretnim workloadu.

Mimochodem pri tom soucasnem porovnavani, na 9.1 probehne rm -r ports 
vyrazne rychleji, nez na 8.3. Neco kolem 5 sekund oproti 25. Ale opet 
nedokazu rict, cim presne to je, jen to konstatuju jako pozorovanou 
zmenu. (a co je kde v bufferech, nemam tuseni)

> Mimochodem, nemyslim, ze vyber IDE/AHCI je pouze otazkou softwarove
> konfigurace (nebo verze) OS. Jde o protokol, kterym v dane chvili je
> hardware ochoten mluvit - coz se vetsinou nastavuje v BIOSu. A myslim,
> ze na chip v rezimu AHCI nelze mluvit ATA protokolem. Takze "pouziva
> AHCI" taky vypada spis na "jiny/jinak nastaveny hardware" nez "jina
> verze OS".

S tim AHCI je to taky "kus od kusu". Na jednom serveru mi to nechce 
behat vubec, at nastavim v BIOSu cokoliv, na dalsim to "vynutit" slo (na 
8.2), na tom Ciscu s 9.1 AHCI funguje automaticky, ale zase v BIOSu byla 
puvodne zapnuta nejaka uzasna featura, ze se kanaly, na kterych neni pri 
bootu zadny disk, uplne vypnou, takze je system za provozu uz nevidi a 
neda se na ne dodatecne "hot swapnout" dalsi disk. Az kdyz jsem tu 
featuru v BIOSu vypnul, tak system (camcontrol) vidi i ty prazdne kanaly.

A jeste myslim, ze jsem na nekterych serverech mel nejaky "auto" rezim, 
kde se IDE/AHCI pouzilo podle toho, co chtel pouzit OS.

Mirek