nepristupnost stroje

[Dan Lukes]

Antonin Vecera napsal/wrote, On 01/30/08 07:41:
> Pokud na tento pc zacnu po LAN kopirovat nejaky velky soubor, tak
> 1. se na nej nelze prihlasit pres ssh
> 2. nelze provest vypis adresare (ls)
> 
> Pricemz pokud se jeste pred zapocetim kopirovani na nej prihlasim pres
> ssh a spustim si tam "top", tak ten behem onoho kopirovani bezi bez
> problemu.

> Jevi se mi to tak, ze ten souvisly zapis si urve disk jen pro sebe.

	Nikoliv "jen". Jde proste o dva konkurencni procesy, ktere vyuzivaji disk.

> ocekaval bych, ze diky multitaskingu se o ten disk ty ulohy dokazou podelit.

	Ony se o nej deli. Bohuzel, ne v takovem pomeru, v jakem bysis pral. Na 
urovni pristupu k IO neexistuje zadna prioritizace. Kdyz budes mit dva 
procesy zadajici pristup k disku, budou se o nej delit rovnym dilem. A 
nevyresis to prioritami na urovni scheduleru - ten prideluje procesor. 
Jenze toho je v tomhle pripade dost. Aplikace A pozada o praci s diskem 
a ceka na jeji dokonceni - dost dlouho, aby si o operaci s diskem 
pozadala aplikace B a take usnula pri cekani. I kdyby jedna z nich mela 
prioritu nejvyssi a druah nejnizsi, pri praci s diskem se budou stridat 1:1

	Ono to ale ve skutecnosti bude jeste daleko horsi. Mezi aplikaci a 
diskem je fronta (buffer), ktery umozni aplikaci zadat i takovy IO 
pozadavek, ktery vyusti ve vic low-level IO operaci.

	Pokud jedna aplikace provadi jeden ohromny zapis, kdezto druha aplikace 
provadi vetsi mnozstvi izolovanych mensich cteni (nebo i zapisu) tak se 
budou delit patrne v daleko horsim pomeru nez 1:1. Aplikace A totiz 
narve do bufferu pozadavku "co to da". Pak tam aplikace B narve svuj 
jeden (dva, tri) pozadavky. Aplikaci A zastavi limit na velikost buferu, 
aplikaci B to, ze ona v tehle chvili vic dat nechce a tak ceka na 
vyrizeni. System se postupne probije tou spoustou pozadavku aplikace A 
(coz trva dlouho, obe aplikace stoji). Uvolni aplikaci A k behu a 
vyrizuje pozadavky aplikace B. To sice trva podstatne kratsi dobu (je 
jich malo), ale presto dost dlouho na to, aby aplikace A znovu naplnila 
frontu "co to da" a zablokovala se. Aplikace B zpracuje vysledek sve 
operace a zase si do fronty da svych par pozadavku - a znovu bude cekat 
dlouho, nez se na ne dostane rada.

	Jeste ke vsemu, vyrizovani jednotlivych operaci trva vyrazne dele - 
pokud nezapisuji do kontinualni oblasti disku, pak se mezi pozadavky 
seekuje. Dokonce i kdyz zapisujes do kontinualniho bloku, je 
pravdepodobne, ze nez zadas zapis do dalsiho sektoru, sektor z pod hlavy 
"ujede" a prestoze operujeme hned s dalsim, musime cekat nez se nam 
znovu dostane pod hlavu. Castecne to eliminuje moznost zadat k zapisu 
vice sektoru najednou, takovehle bloky jsou ale pomerne male.

	Jinymi slovy - ty procesy se o pristup k disku deli. Dokonce v jistem 
ohledu spravedlive (ta aplikace, ktera disk potrebuje vic ho take vic 
dostava). Ale nedeli se o nej tak, jak by ti bylo prijemejsi.

	WC tenhle problem vyrazne omezuje - prinejmensim minumalizuje 
rotational-delay a seekovani, ktere tvori podstatnou slozku "cekani".

> Nevi nahodou nekdo, jestli to jde nekde vyladit tak, aby se ten
> stroj/disk nestaval nepristupnym???

	Pravdepodobne by slo prepsat diskovy sybsystem a ovladace tak, aby se 
choval za tehle podminek lepe. On je napsany tak, aby se choval dobre v 
typickych podminkach, ktere ale nejsou tvuj pripad.

	Osobne si myslim, ze to vyladit pujde. Nejdriv zapnes zpatky to WC. A 
pak zacneme resit, co jsi se jeho vypnutim snazil vyresit a najdeme 
vhodnejsi reseni TOHOTO problemu.


						Dan