2008/1/30 Dan Lukes <[EMAIL PROTECTED]>: > 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. >
Dekuji za vysvetleni. Velice zajimave. Vypnutim te zapisovaci cache jsem chtel zajistit odolnost stroje (dat na disku) proti vypadku napeti. Mam to jako sdilene domaci uloziste, kde ta rychlost je i pri vypnute WC dostacujici. Neni u toho klavesnice, ani monitor. Chtel bych, aby to pri event. vypadku site samo zkontrolovalo disk a najelo. Bez ztraty dat. Nechci prenaset monitor kdesi z pudy a opravovat disk. Kdesi jsem cetl, ze tu konzistenci dat by meli zajistit "Softupdates", ale ze z hlediska sve spravne funkce pozaduji, aby kdyz reknou disku "toto zapis" a disk rekne "je to zapsane", tak aby to bylo opravdu zapsane, a ne nekde v kesi. Proto jsem vypnul WC. Antonin Vecera -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
