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
--
FreeBSD mailing list ([email protected])
http://www.freebsd.cz/listserv/listinfo/users-l
