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