Tvrdý náraz do měkkých aktualizací (diskuse)

[8an]

Krásným potvrzením toho, jak jsou soft updates složité, je bug, který jsem hlásil na konci roku 2006. Opraven byl teprve letos na jaře ve FreeBSD 7.2, trvalo to tedy dva a půl roku.

[trekker.dk]

It seems waiting for a minute before remount helps.

vidím nějakou souvislost s:

Řetěz závislostí aktualizací občas vyústí v to, že je mezi návratem z volání rmdir() a odpovídajícím snížením počtu odkazů nadřazeného adresáře dvouminutové zpoždění

[Radek]

Opravte mne, pokud se pletu, ale není tento jemný mechanismus stejně zbořen při použití NCQ?

[frr]

Není, pokud všechny vrstvy od FS níž (bloková, SCSI, NCQ) respektují "IO bariéry". Bariéra je obecné označení pro speciální příkaz, kterým se zakazuje přehazovat pořadí běžných IO příkazů dopředu/dozadu přes tuto bariéru. Bariéra je z IO fronty odstraněna ve chvíli, kdy se fyzicky sync()nou všechny příkazy, které šly před ní. Taky už jsem slyšel, že to některé disky nerespektují, aby měly v benchmarcích lepší výsledky... A třeba v linuxový DeviceMapper na bariéry kašle.

[Radek]

Díky za vysvětlení. Jestli tomu dobře rozumím, tak ale měkké aktualizace vyžadují vkládání bariér mnohem častěji (alespoň v případě metadat) než žurnálovací systémy. A pokud si pamatuji dobře nedávné testy distribucí, zapnutí bariér srazilo openSUSE na kolena v porovnání s ostatními distry, které bariéry defaultně zapnuté neměly. Znamenalo by to, že údaje "o 5% vs. o 20-30% horší než ramdisk" mohou být značně nadsazené... Odstup openSUSE v diskových operacích byl tehdy v řádu desítek procent. Nebo se pletu?

[Zdeněk Štěpánek]

(joke)

Ta holka sice vi o cem mluvi, ale ja to doted nevim...

Zdenek

[Jakub Lucký]

Taky mám pocit, že mi ta slečna nadává

[Rezza]

 Ta holka nema rada, kdyz ji nekdo prirovnava k blondatemu prislusenstvi na gauc :D Ale jako jinak klobouk dolu.

[frr]

BTW, zase jednou klobouk dolů před autorem českého překladu. Tohle je práce pro korejského kata. Běžná profesionálka s diplomem z fildy by si na tom osumkrát vylámala zuby.

[Luboš Doležel (Doli)]

Běžná profesionálka s diplomem z fildy by si na tom osumkrát vylámala zuby.

Taková nějaká ženská z fildy mě "učila" angličtinu na ČVUT a člověk musel mít neustále nastartovaný Google, aby jí mohl ukazovat, že to mám fakt dobře a ten jazyk jí jde hůř než půlce třídy :-/

[frr]

A byla aspoň hezká? Musela být z učení na ČVUT nešťastná. Nešťastná hezká holka je snesitelnější, než naštvaná zapšklá větev...

[M_P]

Jedna byla ošklivá, druhá šeredná a třetí taky z ČVUT. ;)

[Radek]

Když slyším podobné řeči, říkám si, jak to na technikách bývá při pohledu z druhé strany.

[stativ]

Hmm… nemůžu si pomoct, ale až na pohlaví jsem úplně stejný případ jako Cecilia. A nejsem grad student (zatím?).

[shaga]

Tohle je jednoduchá technická angličtina. Problém překladu není v jazyce, ale v oborové terminologii. Autor překladu by si - patrně - pro změnu vylámal zuby například na odborném lékařském textu.

Profesionál zvládá překlady textů z různých oborů s dopomocí kvalitních slovníků a kozultací oborového experta. "Běžná profesionálka z fildy" pak zvládne kupříkladu i beletrii. A to je dost jiný sport než technické texty.

[frr]

Přesně tak - jde o precizní znalost spisovného cílového jazyka a zároveň o znalost odborné stránky. Slovník oborové terminologie nestačí, chce to taky věcně chápat, o čem je řeč, mít přehled o problematice. Překládat dlouhá odborná souvětí slovo od slova nedává dobrý výsledek - lepší postup je, přečíst a pochopit třeba odstavec (případně dohledat a dostudovat širší kontext), a pak to věcně správně "přebásnit" do cílového jazyka tak, aby se to dobře četlo. Problém je v tom, že ten mlčky předpokládaný kontext okolo, potřebný pro dobrý překlad, je leckdy docela rozsáhlý (střeva filesystémů jsou docela dobrý příklad). Případná konzultace s expertem předně musí u překladatele padnout na úrodnou půdu - jinak by to ten expert mohl rovnou překládat celé sám.

Proto mi srdce vždycky poskočí radostí, když vidím dobře zvládnutý odborný překlad. Velmi často se totiž setkávám s překlady, které překládal nějaký studovaný filolog, třeba i s odborným slovníkem, ale s naprostou neznalostí cílového oboru. Když odborný slovník nabídne tři varianty překladu konkrétního slova (pro různé kontexty), má překladatel třetinovou šanci, že se trefí správně aspoň do toho izolovaného slovíčka, nemluvě o kontextu

Mimochodem, rozhodně bych neřekl, že ten text je obsahově jednoduchý. Je to docela pokročilý level programátorštiny. Připouštím, že není nijak přehnaně nápaditý a zašmodrchaný v ohledu jazykozpytném

Slušný překladatel ví sám nejlíp, na který obor stačí, a na který konkrétní materiál stačí. Třeba já jako šroubovák počítačovej si příležitostně docela dobře počtu v různých anglicky psaných výzkumných zprávách z "medicínských" oborů (když nějaký "Journal of" něco bezplatně vystaví), nacházím tam metodické hnidy typu špatně označené osy v grafech, nevhodně volený typ grafu, ošklivě poskládaná tabulka apod. Kromě toho ti výzkumníci mají občas trochu problém se srozumitelně a gramaticky správně vyjadřovat. Nemluvě o autorech, pro které Angličtina není rodnou řečí... Zato když občas u svého doktora dostanu zprávu z vyšetření (v češtině, mé rodné řeči) a snažím se ji přečíst, jdou mi z toho oči šejdrem - je to jak oborově specifický těsnopis Překlad takové zprávy bych si nikdy nelajsnul.

[M]

 Vám přijde termín "měkké aktualizace" dobrý? Mě to teda docela vyděsilo...

[trekker.dk]

Jako vždy je vítán lepší návrh. (Jako vždy se ovšem neobjevil hned v prvním příspěvku.)

[thingie]

Nechat soft updates, přirozeně. Proč to překládat? Měkké aktualizace popravdě ani nevypadá o nějak moc víc česky než soft updates, ani to lépe neobjasňuje ten pojem, a vůbec mě nenapadá co víc to přináší, krom toho, že se s tím pak v českém textu lépe pracuje, protože se to narozdíl od soft updates dá skloňovat. Nic moc, teda.

[Filip Jirsák]

A proč vůbec překládat celý článek? Asi pro ty, kteří si to chtějí přečíst česky. A pro ty je potřeba vymýšlet české ekvivalenty k cizojazyčným termínům. Je možné, že se první překlad nepodaří a někdo vymyslí nějaký jiný, lepší; taky je možné, že se ujme počeštěná varianta. Ale kdyby se rezignovalo na překládání termínů a všechny termíny se nechávaly v originále, budete v takovémhle článku mít česky akorát spojky a předložky.

[trekker.dk]

A proč vůbec překládat předložky a spojky? Vždyť ty by ten krásný anglický článek jenom hyzdily. (A té práce, co bych si ušetřil, prostě jenom označit zdroják, ťuk prostředním a mám hotovo.)

[thingie]

Blbost. Tohle je pojem, který pokud náhodou nemá naprosto zřejmou, jasnou a jednoznačnou českou verzi, tak jí nebude mít nikdy. Tu očividně nemá. Nemluvě o tom, že případné do češtiny ohnuté „soft updaty“ se vyslovují a znějí mnohem lépe než „měkké aktualizace“, což takovému zbytečnému umělému překladu taky dává slušnou ránu. Jediný smysl je pak skutečně jenom v tom, mít tam něco co vypadá „česky“, aby se dalo říct, že je to překlad, ačkoliv je to zbytečné, protože se dá ohnout ten původní termín a vypadá to česky skoro stejně. To o těch předložkách a spojkách je naprostý nesmysl.

[Andrej Herceg]

Slovné spojenie "měkké aktualizace" nie je asi najlepšie, ale rovnako zlé je aj originálne "soft updates". Ak niekto netuší, čo to má znamenať, tak z toho názvu sa to nedozvie (pri mäkkých aktualizáciách si aspoň nikto nebude myslieť, že ide o nové verzie programov).

PS: "Soft updaty" je tá najhoršia možná verzia. ;)

[thingie]

Vzhledem k tomu, že vysvětlování co to je se věnuje půlka celého článku, tak mi není úplně jasné, jak by se to lidi mohli dozvědět jenom z názvu…

[Filip Jirsák]

A jak by ta zřejmá, jasná a jednoznačná česká verze asi tak vznikla? Jedině tak, že ji někdo jednou jako první použije v překladu. Stejně jako u všech ostatních pojmů, které se v češtině používají přeložené. Stačí se podívat na ten článek, kolik tam máte přeložených termínů, které před pár lety v češtině (v tomto významu) neexistovaly: souborový systém, soubor, blok (na disku), zápis (na disk), aktualizace…

[thingie]

No nepochybně. Kolik lidí se česky baví o nějakých soft updates?

[Filip Jirsák]

Článek byl zobrazen téměř třitisíckrát, takže můžeme jako odhad vzít, že dva tisíce lidí si ho přečetlo (pokud se vícenásobné zobrazení jedním uživatele počítá jen jednou). Ale i kdyby se tím zabývali jenom dva lidé, stačí to. Pokud vám vadí, že je článek česky, přečtěte si anglické materiály, je jich dost. Varianta napůl česky a napůl anglicky nemá smysl, není to pořádně ani jeden jazyk a je to jen zdegenerovaná čeština na cestě k pidgin angličtině.

[trekker.dk]

Jj, není nad pořádný flame o tom, jestli překládat/nepřekládat. I když se jako vždycky dohadujete úplně zbytečně, protože dokud budu překládat já, tak se termíny překládat budou, dokud Robert neřekne jinak.

[Theodor]

No třeba my tady, že ... . A jen bych podotkl, že je pro mne český název docela podstatný, kdyby mi ho nepředložil autor, něco si vymyslím sám. Protože "přemýšlím" v češtině.

[petr_p]

„soft updaty“ znějí česky naprosto hrozně, protože jste nevyskloňovat přívlastek.

[kolemjdouci]

asi kvuli tomu nebudu spat !

[Josef Kufner]

Tak mám takový pocit, že by to chtělo hybrida. Dokud se nenarazí na kruhové závislosti, tak hezky řadit a nepoužívat žurnál -- odpadne režije s udržováním žurnálu. A v okamžiku kdy se narazí na kruhovitý problém, vykašlat se na ty všechny složitosti, použít žurnál pro tu jednu nebezpečnou operaci a pak v klidu pokračovat s bezpečným pořadím. Takže bych to celé viděl jako hezkou optimalizaci nějakého žurnálovacího filesystému.

[j]

Precist jeste jednou ;), potiz neni v tim, ze by to nefungovalo, ale v tom, ze se to hodne blbe implementuje a jeste hur udrzuje. Pokud se nekde deje neco co by nemelo, tak se v tom bude hodne blbe hledat chyba. A kdokoli by chtel pridat nejakou novou uzasnou funkcionalitu by musel prekopat celej FS => s pravdepodobnosti 101% by toho vic rozbil nez vylepsil.

[Palo]

Nemam rad taketo optimalizacie ktore sposobuju strasidelne programatorske finty kombinovane s uzamknutim celeho FS proti rozsirovaniu o nove vlastnosti. Naozaj mame tie disky take pomale ze to nestaci?

Nie je skor riesenim nejaky HW napr pridanim dalsieho cachovacieho mechanizmu medzi pamat a disk? Co takto bateriovo zalohovana RAM. Vlastne vsetko sluzi iba na to aby sa predislo poskodeniu pri odpojeni napajania. Pritom by ale stacil nejaky mechanizmus ktory by zabezpecil ze ked sa odpoji napajanie tak zostane nejaka cast pamate stale zapamatana alebo niekde bude dostatok elektriny na to aby sa zmeny z medzicache zapisali na HD.

[Radek]

Na druhou stranu já s povzdechem sleduji, jak se dnes zbytečně plýtvá výpočetním výkonem podle hesla "máme silné procesory". Je fajn, že se někdo snaží kus kódu vyladit, a že jde až na hranici lidských schopností.

[trekker.dk]

Jenže tohle není ten případ - o výpočetní výkon tu vůbec nejde, protože při operacemi s disky nejvíc času zabírá čekání na ten disk.

A navíc tady se jedná o implementaci souborového systému nějakým způsobem, který zajišťuje konzistenci po pádu. O ladění výkonu nebyla řeč.

[Radek]

Jenže tohle není ten případ - o výpočetní výkon tu vůbec nejde, protože při operacemi s disky nejvíc času zabírá čekání na ten disk.

Ale princip je stejný, nebo ne? Namísto jemné implementace se využije síly dnešních počítačů.

A navíc tady se jedná o implementaci souborového systému nějakým způsobem, který zajišťuje konzistenci po pádu. O ladění výkonu nebyla řeč.

V úvodním odstavci je zmíněn pokles výkonu vůči ramdisku jen o 5% (oproti 20-30% u žurnálu). Pochopil jsem to tak, že výkon je hlavní motivací pro měkké aktualizace. Konzistenci zajišťuje žurnál stejně tak.

[trekker.dk]

Ale princip je stejný, nebo ne? Namísto jemné implementace se využije síly dnešních počítačů.

Není. Neexistuje tady nic jako jemná implementace a využívání síly dnešních počítačů. Prostě jde o dva různé způsoby zajištění konzistence souborového systému. A i kdyby - jak už jsem řekl, nejvíc času při operaci s disky zabere čekání na ten disk. Takže i když uděláš superoptimalizovanou implementaci, která bude o polovinu rychlejší, než neoptimalizovaná, v celkovém čase se to projeví o pár procent - zbytek času se bude optimalizovaně čekat, až disk udělá, co je mu poručeno.

V úvodním odstavci je zmíněn pokles výkonu vůči ramdisku jen o 5% (oproti 20-30% u žurnálu). Pochopil jsem to tak, že výkon je hlavní motivací pro měkké aktualizace. Konzistenci zajišťuje žurnál stejně tak.

Já jsem z toho textu nějak nevyčetl to, že by FFS používal žurnál.

[Radek]

Vycházel jsem z tohoto ostavce:

U běžných pracovních zátěží je často odchylka výkonnosti od souborového systému uloženého v paměti do 5 %. Starší verze FFS, ...

Chápu Vás tedy dobře, že stejný souborový systém implementovaný žurnálem také dosáhne pouze 5% poklesu výkonosti oproti ramdisku?

[Kvakor]

Bateriově zálohvaná RAM je na řadičích už nějakou dobu, spíš by to chtělo bateriově zálohovanou RAM v disku - nemusela by to být přímo baterie, možná by stačil superkondenzátor, který by udržel elektroniku disku dost dlouho "naživu", aby se obsah celé diskové cache zapsal na nějaké vyhražené místo, případně do malé FLASH paměti, určené jen pro tento účel, ze které by se při přištím zapnutí načet a zapsal tam, kam má. Možná, že druhém případě by dokonce stačila jenom rotační energie samotných ploten - synchonní motorek by se přepnu do režimu generátoru a napájel by elektroniku než by se zapsala cache do FLASH paměti.

[Filip Jirsák]

Nebylo by jednodušší prostě to zapsat na ten disk?

[Kvakor]

Bylo, jenže to by znamenalo seekování, energeticky nejnáročneší možnou činnost disku, v patologickém přípaďě od okraje ploten až k ke středu, při vypnutém NCQ by to mohlo být i několikrát více.

Takže buďto by musel mít disk opravdu velký superkondenzátor, aby utáhl veškerou elektroniku disku jedoucí na plný vykon po maximální možnou dobu zápisu na disk, nebo superkondenzátor jen tak velky, aby stačil seeknou na předem určenou pozici na plotně (např. těsně vedle parkovací stopy) a vysypat tam obsah cache (včetně informací, kam má být jaký sektor zapsán) v určitém, vždy konstaním čase, protože obnovení napájení bude dost času a energie na prečtení a zapsání tak, jak to má být správně.

A z pohledu výrobce se nesmí zapomínat, že zatímco superkondenzátory jsou drahé, místo na disku je velmi levné (každý disk má nějaké nepoužité místo navíc, už jen pro self-testy a relokaci sektorů) a složitější firmware při množství vyrobených kůsů znamená zanedbatelnou položku.

[Josef Kufner]

No naštěstí informace o výpadku napájení dává už sám zdroj, který ty kondenzátory má dostatečně veliké.

[frr]

Souhlas. Dnešní disky mají cache maximálně 32-64 MB, při sekvenční rychlosti u středu řekněme 60 MBps. Takže by disk potřeboval energii na seek ke středu plotny (v nejhorším případě odhadem 20 ms) a na 1 s sekvenčního zápisu. Možná by to bylo levnější než po nějakou dobu udržovat baterkou obsah DRAM cache. Jedna vteřina provozu se seekem směrem k parkovací poloze. Kolik to může stát energie, 20 J? Superkondenzátory mívají přirozené jmenovité napětí okolo 2.5 V na článek. To by vycházelo řádově na 10 F potřebné kapacity, spíš trochu víc (nešel by využít až k 0 V). Ten koďan by nebyl úplně malej Třeba tenhle 25F kousek od Maxwellu je váleček průměr 16 krát 25 mm.

http://www.maxwell.com/pdf/uc/datasheets/DATASHEET_HC_series_1013793.pdf

Tomuhle dobrému nápadu by mohlo docela pomoct, kdyby disk měl šanci se okamžitě dozvědět, že napájecímu zdroji počítače vypadla šťáva na vstupu (zhasla střídavina). Kdyby si disk musel sám zjišťovat, že došlo k nějakému poklesu napájecích větví, tak už propásne příležitost využít energii, která ještě zůstala naakumulovaná v napájecím zdroji. Nejvíc energie akumuluje primár napájecího zdroje (aspoň u zdrojů se vstupem 230V st.). Fakt je, že když uvažuju jako optimistický případ třeba 470uF kondík a zdroj s aktivním PFC schopný pracovat v rozsahu 100-240V st. napájený ze sítě 240V st., vychází mi využitelná akumulovaná energie na cca 20 Joulů (Watt*Sekunda), což je řekněme 100 ms provozu celého kompu. To by ten koďan na primáru zdroje musel být řádově větší Taky kdyby tomu výpadku předcházelo podpětí v té vstupní střídavině, koďan na primáru by ve chvíli výpadku neměl skoro žádnou zbytkovou energii...

Když by superkondenzátor zabudovaný do disku měl krmit zmíněný nouzový zápis, potřeboval by patrně jako doprovod ještě nějaký spínaný zdroječek/stabilizátor a taky odpojovací FET v každé napájecí větvi na vstupu disku, aby nekrmil zpátky už chcíplý počítač Celé to znamená docela dost součástek navíc.

Stejnak to problém bezezbytku neřeší, protože hodně dat bude v okamžiku výpadku v bufferech OS...

[Filip Jirsák]

Podle mne z toho ze všeho stejně jednoznačně vychází, že pokud někomu záleží na datech, má mít počítač připojený k UPSce, se kterou je schopen se domluvit, že dochází šťáva a je potřeba se vypnout. A všechny ostatní serepetičky s častou synchronizací disku jsou pak zbytečné.

[8an]

Nezapomínejte na druhou situaci, kdy jsou soft updates nebo jejich ekvivalent potřeba: pád systému.

[Filip Jirsák]

Pád systému znamená hardwarovou chybu nebo chybu operačního systému. A v takovém okamžiku může snaha někam rychle něco zapsat být přesně tou akcí, která způsobí poškození dat.

[frr]

Jo, jasně V současnosti určitě jediný možný pragmatický přístup. Přesto mě okouzluje teoretická představa, že by si disk stihl zapsat svojí cache na plotnu, ať se děje co se děje. Superkondík by měl stejnou životnost jako disk. Baterky v UPSce mají životnost tak dva roky bůhví jestli. Kolik já už viděl UPSek co měly baterku dávno sušenou, nebo se historickým vývojem přihodilo, že se časem dostaly do zóny přetížení... To jistě nebyly zodpovědně správcované UPSky - nicméně to byla realita

[melkors]

Uz jsem videl take par vyhorelych UPS ...

Nejefektnejsi to bylo v datovem centru, kde u jedne masiny odkracel zdroj a zpusobil kolaps UPS pro cely sal.

[graviton]

s/Yale Pratt/Yale Patt/