abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

dnes 20:00 | Nová verze Ladislav Hagara | Komentářů: 0
dnes 19:33 | Pozvánky

Pražská Fedora 27 Release Party, oslava nedávného vydání Fedory 27, se uskuteční 19. prosince od 19:00 v prostorách společnosti Etnetera (Jankovcova 1037/49). Na programu budou přednášky o novinkách, diskuse, neřízený networking atd.

Ladislav Hagara | Komentářů: 0
dnes 18:11 | Nová verze

Byla vydána verze 2.11.0 QEMU (Wikipedie). Přispělo 165 vývojářů. Provedeno bylo více než 2 000 commitů. Přehled úprav a nových vlastností v seznamu změn.

Ladislav Hagara | Komentářů: 0
dnes 17:44 | Komunita

Canonical oznámil dostupnost kryptografických balíčků s certifikací FIPS 140-2 úrovně 1 pro Ubuntu 16.04 LTS pro předplatitele podpory Ubuntu Advantage Advanced. Certifikace FIPS (Federal Information Processing Standards) jsou vyžadovány (nejenom) vládními institucemi USA.

Ladislav Hagara | Komentářů: 1
dnes 16:11 | Zajímavý software

Společnost Avast uvolnila zdrojové kódy svého dekompilátoru RetDec (Retargetable Decompiler) založeného na LLVM. Vyzkoušet lze RetDec jako webovou službu nebo plugin pro interaktivní disassembler IDA. Zdrojové kódy RetDec jsou k dispozici na GitHubu pod open source licencí MIT.

Ladislav Hagara | Komentářů: 2
včera 11:00 | Zajímavý software
Na Good Old Games je v rámci aktuálních zimních slev zdarma k dispozici remasterovaná verze klasické point&click adventury Grim Fandango, a to bez DRM a pro mainstreamové OS včetně GNU/Linuxu. Akce trvá do 14. prosince, 15:00 SEČ.
Fluttershy, yay! | Komentářů: 6
včera 07:22 | Pozvánky

Konference InstallFest 2018 proběhne o víkendu 3. a 4. března 2018 v Praze na Karlově náměstí 13. Spuštěno bylo CFP. Přihlásit přednášku nebo workshop lze do 18. ledna 2018.

Ladislav Hagara | Komentářů: 0
12.12. 20:22 | Nová verze

Před měsícem byla vydána Fedora 27 ve dvou edicích: Workstation pro desktopové a Atomic pro cloudové nasazení. Fedora Server byl "vzhledem k náročnosti přechodu na modularitu" vydán pouze v betaverzi. Finální verze byla naplánována na leden 2018. Plán byl zrušen. Fedora 27 Server byl vydán již dnes. Jedná se ale o "klasický" server. Modularita se odkládá.

Ladislav Hagara | Komentářů: 6
12.12. 10:22 | Zajímavý článek

Lukáš Růžička v článku Kuchařka naší Růži aneb vaříme rychlou polévku z Beameru na MojeFedora.cz ukazuje "jak si rychle vytvořit prezentaci v LaTeXu, aniž bychom se přitom pouštěli do jeho bezedných hlubin".

Ladislav Hagara | Komentářů: 13
12.12. 07:22 | Komunita

Od 26. do 29. října proběhla v Bochumi European Coreboot Conference 2017 (ECC'17). Na programu této konference vývojářů a uživatelů corebootu, tj. svobodné náhrady proprietárních BIOSů, byla řada zajímavých přednášek. Jejich videozáznamy jsou postupně uvolňovány na YouTube.

Ladislav Hagara | Komentářů: 0
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (8%)
 (1%)
 (1%)
 (1%)
 (75%)
 (14%)
Celkem 986 hlasů
 Komentářů: 45, poslední 1.12. 19:00
    Rozcestník

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

    7. 8. 2009 | Jirka Bourek | Programování | 6298×

    Když souborový systém existuje dostatečně dlouho, dříve či později téma měkkých aktualizací [soft update] někdo nadhodí, obvykle v podobě „Pche, proč jste vy lidi od Linuxu tak hloupí? Prostě použijte měkké aktualizace jako BSD!“

    Obsah

    Originál tohoto článku pro LWN.net napsala Valerie Aurora (dříve Hensonová).

    … Na takový komentář [viz perex] většinou nebude žádná přímá odpověď a konverzace bude tiše plynout okolo něj, jako proud okolo inkoustově černého balvanu. Proč to tak je? Jde o čisté NIH (Not Invented Here, vynalezeno někým jiným) na straně vývojářů Linuxu (a Solarisu a OS X a AIX a ...) nebo jde o něco hlubšího? Proč jsou měkké aktualizace tak slavné a přitom tak zřídka implementované? V tomto článku budu dokazovat, že měkké aktualizace jsou jednoduše řečeno příliš těžko pochopitelné, implementovatelné a udržovatelné na to, aby mohly být součástí hlavního proudu vývoje souborových systémů – přičemž se zároveň pokusím vysvětlit, jak fungují. Ó, ta ironie!

    Měkké aktualizace: Pohled z 20 km

    link

    Měkké aktualizace jsou jedna z technik pro udržování konzistence souborového systému na disku. Základním problémem je to, že souborový systém není vždy ukončen čistě – řekněme kvůli pádu operačního systému nebo výpadku napájení – a když k tomu dojde uprostřed jeho aktualizace (například při mazání souboru), stav souborového systému na disku může být nekonzistentní (poškozený). Původním řešením tohoto problému bylo spustit fsck na celý souborový systém a nekonzistence najít a opravit; příkladem souborového systému, který používá tento přístup, je ext2. (Všimněte si, že toto použití fsck – obnova po nečistém ukončení – je odlišné od použití fsck ke kontrole a opravě souborového systému, který byl poškozen z nějakého jiného důvodu.)

    Přístup fsck má zjevné nevýhody (trvá dlouho, je možná ztráta dat), takže vývojáři souborových systémů vyvinuli nové techniky. Nejpopulárnější a dobře známé je logování nebo žurnálování: Předtím, než začneme do souborového systému zapisovat změny, zapíšeme krátký popis této změny (záznam v žurnálu) do oddělené oblasti na disku (žurnál). Když systém padne uprostřed zápisu změn, jednoduše změny dokončíme přehráním záznamů v žurnálu při příštím připojení souborového systému.

    Měkké aktualizace místo toho používají dvoukrokový přístup k obnově po pádu. První je, že se zápisy na disk pečlivě řadí tak, aby v případě pádu (či v jakékoliv jiné situaci) jediné možné inkonzistence spočívaly v tom, že je nějaká struktura souborového systému alokována, když se ve skutečnosti nepoužívá. Druhý je ten, že po pádu se na pozadí spustí fsck nad snímkem [snapshot] souborového systému (o tom více později), který vyhledá a uvolní struktury v souborovém systému, které jsou chybně označeny jako alokované. Měkké aktualizace zjednodušeně řadí zápisy na disk tak, že jsou možné pouze relativně neškodné inkonzistence, které se následně na pozadí opraví kontrolou a opravou celého souborového systému. Výsledky benchmarků jsou poměrně ohromující: 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, která k poskytnutí stejné spolehlivosti používala synchronní zápisy a fsck na popředí, často běží o 20-30 % pomaleji než souborový systém uložený v paměti.

    Krok 1: Závislosti aktualizace

    link

    Prvním krokem implementace měkkých aktualizací je zjistit, jak seřadit zápisy na disk tak, aby byly po pádu jedinou možnou chybou inody a bloky, které jsou chybně označeny jako alokované (přestože jsou ve skutečnosti volné). Aby se dosáhlo tohoto cíle, autoři nejprve určují nějaká pravidla, která je potřeba dodržovat, když se změny zapisují na disk. Cituji z pojednání:

    • Nikdy se nesmí ukazovat na strukturu předtím, než je zinicializována (tj. inode musí být inicializován předtím, než se na něj odkazuje záznam v adresáři).

    • Zdroj se nikdy nesmí znovuvyužít předtím, než se vynulují všechny předchozí odkazy na něj (tj. ukazatel inodu na datový blok musí být vynulován předtím, než lze znovu alokovat nový inode na tomto diskovém bloku).

    • Nikdy neresetovat starý ukazatel na používaný zdroj předtím, než je nastaven nový ukazatel (tj. když je soubor přejmenováván, neodstraňovat staré jméno inodu do doby, než se zapíše nové).

    Páry změn, kde jedna změna musí být zapsána na disk předtím, než lze zapsat druhou změnu podle pravidel výše, jsou nazývány závislosti aktualizace. Další příklady závislostí aktualizace si můžeme vzít ze situace, kdy je poprvé zapisován první blok v souboru. První závislost aktualizace je ta, že v blokové bitmapě, která obsahuje informaci o tom, které bloky se používají, musí být zaznamenáno, že blok se používá, předtím, než se nastaví ukazatel na blok v inodu. Pokud by v tomto okamžiku došlo k pádu, jedinou inkonzistencí by byl bit, který v blokové bitmapě ukazuje, že je blok alokován, přičemž ve skutečnosti není. Jde o únik zdroje, který je potřeba nakonec opravit, ale souborový systém může i s touto chybou pracovat korektně, pokud mu nedojdou volné bloky.

    Další závislostí aktualizace je, že data v samotném bloku musí být zapsána předtím, než lze nastavit ukazatel na blok v inodu (společně s navýšením velikosti inodu a s tím spojenými aktualizacemi časových značek). Pokud by to tak nebylo, pád v tomto okamžiku by mohl způsobit, že se v souboru objeví nesmysly – to je také potenciální bezpečnostní díra, pokud tyto nesmysly pocházely z jiného souboru. S tímto řazením pád povede k úniku bloku (označen jako alokovaný, ale není), který náhodou obsahuje data, která jsme se pokoušeli zapisovat. Výsledkem je, že zápis do bitmapy a zápis dat do bloku musí být (v libovolném pořadí) dokončen předtím, než se zapíší aktualizace ukazatele na blok v inodu, velikost a časové značky.

    Tato pravidla pro řazení zápisů nejsou u měkkých aktualizací nová; původně byla vytvořena pro zápisy v "normálním" souborovém systému FFS. V původním kódu FFS je řazení zápisů vynuceno synchronními zápisy – to znamená, že probíhající operace v souborovém systému (create, unlink atd.) čekají na to, než se každý řazený zápis dostane na disk, než přejdou k dalšímu kroku. Když zápis probíhá, buffer operačního systému obsahující diskový blok, o který se jedná, je zamčen. Jakákoliv další operace, která potřebuje tento buffer změnit, musí počkat, než se dostane na řadu. Výsledkem je, že mnoho operací s metadaty probíhá rychlostí práce disku (tj. vražedně pomalu).

    Krok 2: Efektivní řešení závislostí aktualizace

    link

    Zatím jsme určili, že synchronní zápisy do zamčených bufferů jsou pomalým, nepříjemným způsobem vynucení řazení zápisů do souborového systému. Synchronní zápisy jsou nicméně pro většinu operací v souborovém systému nadbytečné; kromě fsync() většinou nechceme záruku, že výsledek již byl zapsán na stabilní úložiště předtím, než se systémové volání vrátí; jak jsme viděli, kód souborového systému se obvykle zajímá jenom o to, jak jsou zápisy řazeny, nikoliv kdy se dokončí. Co chceme, je zaznamenat změny metadat společně se s nimi spojenými omezeními pro řazení; skutečné zápisy pak můžeme naplánovat dle libosti. Žádný problém, že? Prostě přidáme pár ukazatelů na každý paměťový buffer obsahující metadata, čímž ho spojíme s blokem před a za ním.

    Ukazuje se, že problém tu je: Cyklická závislost. Na disk musíme zapisovat po jednotlivých blocích a každý blok může potenciálně obsahovat metadata ovlivněná více než jednou operací s metadaty. Pokud dvě různé operace ovlivňují stejný blok, může to snadno vést ke konfliktním požadavkům: Operace A vyžaduje, aby byl blok 1 zapsán před blokem 2, kdežto operace B potřebuje, aby byl blok 2 zapsán před blokem 1. Takže není možné zapsat žádné změny bez porušení stanoveného řazení. Co s tím?

    Většina lidí se v tomto bodě rozhodne použít žurnálování nebo kopírování při zápisu [copy-on-write] a tím problém vyřešit. Obě techniky seskupují související změny do transakcí – do sady zápisů, které musí začít platit naráz – a zapisují je na disk takovým způsobem, aby začaly platit atomicky. Když jste ale Greg Ganger a Yale Patt, přijdete se schématem zaznamenávajícím jednotlivé modifikace bloků (jako je aktualizace jediného bitu v blokové bitmapě) a jejich vztahem s ostatními jednotlivými změnami (jedna změna vyžaduje nejprve zapsat jinou změnu). Poté, když zapisujete blok, zamknete ho a procházíte záznamy jednotlivých změn tohoto bloku. Každou jednotlivou změnu, jejíž závislosti ještě nebyly vyřešeny, vezmete zpět a výsledný blok zapíšete. Když je zápis dokončen, změny znovu aplikujete (dopředné přehrávání [roll forward]), odemknete a pokračujete k dalšímu zápisu. Zápis, který jste právě dokončili, mohl vyřešit závislosti aktualizace jiných bloků, takže nyní můžete použít stejný proces (zamčení, zpětné přehrání [roll back], zápis, dopředné přehrání, odemčení) pro tyto bloky. Nakonec jsou všechny závislosti vyřešeny a všechno je zapsáno na disk – to vše, aniž byste narazili na jakékoliv cyklické závislostí. To je v kostce to, čím jsou měkké aktualizace tak unikátní.

    Zaznamenávání změn a závislostí

    link

    Jak tedy záznam změn metadat a s nimi spojených závislostí aktualizace ve skutečnosti vypadá na úrovni datových struktur? Zaprvé je zde dvanáct (podle pojednání z roku 1999) oddělených struktur, které zaznamenávají jednotlivé typy závislostí:

    StrukturaSledovaná závislost
    bmsafemapbitmapy bloku/inodu
    inodedepinode
    allocdirectbloky, na které se odkazuje přímými ukazateli na blok
    indirdepnepřímý blok
    allocindirbloky, na které se odkazuje nepřímými ukazateli na blok
    pagedeppřidávání/odstraňování záznamu v adresáři
    mkdirvytváření nového adresáře
    dirremodstranění adresáře
    freefragfragment, který se má uvolnit
    freeblksblok, který se má uvolnit
    freefileinode, který se má uvolnit

    Každý druh struktury sledující závislost obsahuje ukazatele, které jí umožňují připojení do seznamů spojených s buffery obsahující relevantní struktury na disku. Tyto seznamy kód měkkých aktualizací prochází během operací zpětného a dopředného přehrání u bloku, který je zapisován na disk. Každá struktura závislosti má sadu příznaků popisujících stav závislosti. Příznaky určují, jestli je závislost v současnosti aplikována na s ní spojený buffer, jestli všechny zápisy, na nichž závisí, byly dokončeny a jestli aktualizace popsané v samotné struktuře sledování závislostí byly zapsány na disk. Když jsou nastaveny všechny tři tyto příznaky (aktualizace je aplikována na buffer v paměti, všechny zápisy, na kterých závisí, byly dokončeny a aktualizace je zapsána na disku), strukturu závislosti lze zahodit.

    Na straně 7 pojednání o měkkých aktualizacích z roku 1999 [PDF] začínají popisy specifických druhů struktur závislostí aktualizace a jejich vzájemnými vztahy. Toto pojednání jsem četla nejméně patnáctkrát a pokaždé, když se dostanu na stránku 7, se cítím vcelku dobře a myslím si: „Jo, fajn, asi jsem chytřejší, než když jsem to četla minule, protože to tentokrát chápu“ – pak otočím na stranu osm a vybuchne mi hlava. Zde je obrázek z této stránky:

    soft updates

    A to je obrázek pouze z levého sloupce. Na pravé straně je jenom o trochu méně složitý špagetogram. To pokračuje na šesti stránkách, které popisují každý druh závislosti aktualizace a její postup přes různé seznamy spojené s buffery a strukturami souborového systému a, což je nejdůležitější, jiné struktury závislostí aktualizace. Snažíte se propracovat textem a zápasíte s odstavci jako:

    Obrázek 10 ukazuje struktury zapojené při přejmenování souboru. [Obrázek 10 vypadá podobně jako obrázek výše.] Závislosti sledují stejnou sadu kroků jako ty pro přidávání nového záznamu o souboru s dvěma výjimkami. Za prvé, pokud je potřeba zpětné přehrání, protože inode ještě nebyl zapsán na disk, záznam musí být nastaven na předchozí číslo inodu místo na nulu. Předchozí číslo inodu je uloženo ve struktuře dirrem. Ve struktuře diradd je nastaven příznak DIRCHG, takže kód zpětného přehrání ví, že má použít staré číslo inodu uložené ve struktuře dirrem. Druhá odchylka je, že poté, co je modifikovaný záznam v adresáři zapsán na disk, struktura dirrem je přidána do seznamu úkolů tasklist pracovního démona, aby byl počet odkazů starého inodu dekrementován, jak je popsáno v Sekci 3.9.

    Zkuste to říci třikrát rychleji!

    Nejde o to, že jsou detaily měkkých aktualizací pro pouhé lidi příliš složité na porozumění (i když já osobně bych si nevsadila na to, že Greg Ganger není nadčlověk). Jde o to, že tato složitost odráží nedostatek obecnosti a abstrakce v návrhu měkkých aktualizací jako celku. U měkkých aktualizací musí být všechny operace souborového systému jednotlivě analyzovány, aby se u nich zjistily závislosti aktualizace, každá struktura na disku musí mít zvlášť navrženou strukturu pro sledování závislostí a každá aktualizační operace musí alokovat jednu z těchto struktur a připojit se do sítě dalších zvlášť navržených struktur pro sledování závislostí. Pokud do souborového systému přidáte novou vlastnost, třeba rozšířené atributy, nebo změníte formát na disku, musíte začít od začátku a zjistit relevantní závislosti, navrhnout novou strukturu a napsat rutiny pro zpětné/dopředné přehrání. To je piplavá a zdlouhavá práce a její obtížnost spotřebu pracovních hodin programátorů nijak nevylepšuje.

    Porovnejme vysoce specifický návrh měkkých aktualizací s rozhraním transakcí, které se používá ve většině žurnálovacích souborových systémech a souborových systémech používajících kopírování při zápisu. Když zahájíte logickou operaci (jako je vytvoření souboru), vytvoříte manipulátor [handle] transakce. Pak pro každou strukturu na disku její buffer přidáte do seznam bufferů touto transakcí změněných. Když jste hotovi, transakci uzavřete a předáte ji subsystému žurnálování (nebo kopírování při zápisu), který zjistí, jak ji sloučit s ostatními transakcemi a správně ji zapsat na disk. Uživatel rozhraní transakcí musí jenom vědět, jak otevřít, zavřít a přidat bloky v transakci, zatímco kód transakcí musí pouze vědět, které bloky jsou součástí stejné transakce. Přidání nové zápisové operace nevyžaduje žádné zvláštní znalosti nebo analýzu kromě zapamatování si, že se změněné bloky mají přidat do transakce.

    Nedostatek abstrakce a zobecnění se ukáže znovu, když vystrčí hlavu kombinace řazení závislosti aktualizací a příslušného formátu disku a způsobí podivné chování viditelné pro uživatele. Nejvýraznější příklad se ukáže, když se odstraňuje adresář; dodržování pravidel pro závislosti aktualizace znamená, že záznam „..“ v adresáři nemůže být odstraněn, dokud adresář sám o sobě není na disku odpojen [unlink]. Ř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í. Mezi jinými věcmi to může rozbít i jednoduché rekurzivní rm -rf. Opravou je zfalšovat druhý počet odkazů, který je hlášen do uživatelského prostoru, ale skutečným problémem je příliš těsné spojení mezi strukturami na disku, systémem pro udržování konzistence na disku a strukturami viditelnými pro uživatele. Dlouhé řetězce závislostí aktualizací způsobují problémy jinde, konkrétně během odpojování [unmount] a fsync().

    Fsck a snímek

    link

    Nicméně počkejte, je toho víc! Druhou fází obnovení je u měkkých aktualizací spuštění fsck na pozadí při bootu, přičemž se používá snímek [snapshot] metadat souborového systému. Snímky souborového systému jsou ve FFS implementovány vytvořením řídkého [sparse] souboru o velikosti souborového systému – souboru snímku. Kdykoliv je blok metadat změněn, původní data jsou nejprve zkopírována do odpovídajícího bloku souboru snímku. Čtení nezměněných bloků ve snímku přesměrovává na originál. fsck analyzuje snímek metadat, hledá uniklé bloky a inody. Jakmile doběhne, použije fsck zvláštní systémové volání, které tyto bloky a inody opět označí jako volné.

    Takto implementované fsck za běhu má vážná omezení. První je, že obnovení po pádu stále vyžaduje čtení a zpracování metadat celého souborového systému – sice na pozadí, ale stále jde o spoustu I/O. (Plánování volných bloků (freeblock scheduling) připojuje I/O o nízké prioritě, jako je například to pocházející od fsck běžícího na pozadí, k I/O o vysoké prioritě běžícímu na popředí, aby co nejméně překáželo „skutečné“ práci, ale to moc nepotěší.) Zadruhé to není kompletní kontrola a oprava souborového systému, pouze se hledají uniklé bloky a inody – očekávané inkonzistence. Celý koncept spouštění fsck na souboru snímku, jehož bloky jsou alokované na stejném souborovém systému, předpokládá, že souborový systém není poškozen způsobem, který ponechává bloky označené jako volné, i když jsou ve skutečnosti alokované.

    Závěr

    link

    Koncept měkkých aktualizací lze vysvětlit stručně – řadit zápisy podle několika jednoduchých pravidel, sledovat aktualizace bloků metadat, zpětně přehrávat aktualizace s nevyřešenými závislostmi před zápisem bloku na disk, poté aktualizace zase dopředně přehrát. Když dojde na implementaci, pouze programátoři s hlubokými, encyklopedickými znalostmi formátu souborového systému na disku mohou určit správná pravidla řazení a vytvořit s nimi spojené datové struktury a síť závislostí. Toto těsné spojení datových struktur na disku a jejich aktualizací a pro uživatele viditelných datových struktur a jejich aktualizací může vyústit v podivné, neintuitivní chování, které musí být pokryto dalším kódem.

    Celkově jsou měkké aktualizace sofistikovaný a rozumný nápad – a evolučně slepá ulička. Žurnálovácí souborové systémy a souborové systémy s kopírováním při zápisu se snáze implementují, potřebují méně kódu pro zvláštní účely a vyžadují mnohem méně programátorské práce na rozhraní.

           

    Hodnocení: 100 %

            špatnédobré        

    Nástroje: Tisk bez diskuse

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    7.8.2009 00:58 8an | skóre: 30
    Rozbalit Rozbalit vše Re: Tvrdý náraz do měkkých aktualizací

    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.

    If you build an operating system that even an idiot can use, only idiots will use it.
    7.8.2009 08:45 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Tvrdý náraz do měkkých aktualizací
    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í
    Quando omni flunkus moritati
    7.8.2009 02:52 Radek Černoch | skóre: 14 | Praha
    Rozbalit Rozbalit vše Re: Tvrdý náraz do měkkých aktualizací
    Opravte mne, pokud se pletu, ale není tento jemný mechanismus stejně zbořen při použití NCQ?
    7.8.2009 08:42 frr | skóre: 33
    Rozbalit Rozbalit vše Re: Tvrdý náraz do měkkých aktualizací

    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.

    [:wq]
    7.8.2009 11:18 Radek Černoch | skóre: 14 | Praha
    Rozbalit Rozbalit vše Re: Tvrdý náraz do měkkých aktualizací
    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?
    7.8.2009 08:33 Zdeněk Štěpánek | skóre: 57 | blog: uz_mam_taky_blog | varnsdorf
    Rozbalit Rozbalit vše Re: Tvrdý náraz do měkkých aktualizací
    (joke)

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

    Zdenek
    www.pirati.cz - s piráty do parlamentu i jinam www.gavanet.org - czfree varnsdorf
    Jakub Lucký avatar 7.8.2009 11:24 Jakub Lucký | skóre: 40 | Praha
    Rozbalit Rozbalit vše Re: Tvrdý náraz do měkkých aktualizací
    Taky mám pocit, že mi ta slečna nadává :-)
    If you understand, things are just as they are; if you do not understand, things are just as they are. (Zen P.) Blogísek
    Rezza avatar 7.8.2009 19:46 Rezza | skóre: 25 | blog: rezza | Brno
    Rozbalit Rozbalit vše Re: Tvrdý náraz do měkkých aktualizací

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

    7.8.2009 08:46 frr | skóre: 33
    Rozbalit Rozbalit vše Re: Tvrdý náraz do měkkých aktualizací

    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.

    [:wq]
    Luboš Doležel (Doli) avatar 7.8.2009 09:04 Luboš Doležel (Doli) | skóre: 98 | blog: Doliho blog | Kladensko
    Rozbalit Rozbalit vše Re: Tvrdý náraz do měkkých aktualizací
    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 :-/
    7.8.2009 09:36 frr | skóre: 33
    Rozbalit Rozbalit vše Re: Tvrdý náraz do měkkých aktualizací

    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...

    [:wq]
    7.8.2009 12:05 M_P
    Rozbalit Rozbalit vše Re: Tvrdý náraz do měkkých aktualizací
    Jedna byla ošklivá, druhá šeredná a třetí taky z ČVUT. ;)
    7.8.2009 12:19 Radek Černoch | skóre: 14 | Praha
    Rozbalit Rozbalit vše Re: Tvrdý náraz do měkkých aktualizací
    Když slyším podobné řeči, říkám si, jak to na technikách bývá při pohledu z druhé strany.
    stativ avatar 7.8.2009 17:05 stativ | skóre: 54 | blog: SlaNé roury
    Rozbalit Rozbalit vše Re: Tvrdý náraz do měkkých aktualizací
    Hmm… nemůžu si pomoct, ale až na pohlaví jsem úplně stejný případ jako Cecilia. A nejsem grad student (zatím?).
    Ať sežeru elfa i s chlupama!!! ljirkovsky.wordpress.com stativ.tk
    7.8.2009 10:50 shaga
    Rozbalit Rozbalit vše Re: Tvrdý náraz do měkkých aktualizací
    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.
    7.8.2009 13:28 frr | skóre: 33
    Rozbalit Rozbalit vše Re: Tvrdý náraz do měkkých aktualizací

    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.

    [:wq]
    8.8.2009 02:06 M
    Rozbalit Rozbalit vše Re: Tvrdý náraz do měkkých aktualizací

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

    8.8.2009 03:10 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Tvrdý náraz do měkkých aktualizací
    Jako vždy je vítán lepší návrh. (Jako vždy se ovšem neobjevil hned v prvním příspěvku.)
    Quando omni flunkus moritati
    thingie avatar 8.8.2009 03:19 thingie | skóre: 8
    Rozbalit Rozbalit vše Re: Tvrdý náraz do měkkých aktualizací
    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.
    Růžové lži.
    8.8.2009 10:10 Filip Jirsák | skóre: 67 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Tvrdý náraz do měkkých aktualizací
    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.
    8.8.2009 11:26 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Tvrdý náraz do měkkých aktualizací
    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.)
    Quando omni flunkus moritati
    thingie avatar 8.8.2009 12:40 thingie | skóre: 8
    Rozbalit Rozbalit vše Re: Tvrdý náraz do měkkých aktualizací
    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.
    Růžové lži.
    8.8.2009 12:49 Andrej Herceg | skóre: 43
    Rozbalit Rozbalit vše Re: Tvrdý náraz do měkkých aktualizací
    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 avatar 8.8.2009 13:50 thingie | skóre: 8
    Rozbalit Rozbalit vše Re: Tvrdý náraz do měkkých aktualizací
    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…
    Růžové lži.
    8.8.2009 13:01 Filip Jirsák | skóre: 67 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Tvrdý náraz do měkkých aktualizací
    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 avatar 8.8.2009 13:51 thingie | skóre: 8
    Rozbalit Rozbalit vše Re: Tvrdý náraz do měkkých aktualizací
    No nepochybně. Kolik lidí se česky baví o nějakých soft updates?
    Růžové lži.
    8.8.2009 20:06 Filip Jirsák | skóre: 67 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Tvrdý náraz do měkkých aktualizací
    Č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ě.
    9.8.2009 11:35 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Tvrdý náraz do měkkých aktualizací
    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.
    Quando omni flunkus moritati
    10.8.2009 03:27 Theodor
    Rozbalit Rozbalit vše Re: Tvrdý náraz do měkkých aktualizací
    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ě.
    8.8.2009 16:11 petr_p | skóre: 59 | blog: pb
    Rozbalit Rozbalit vše Re: Tvrdý náraz do měkkých aktualizací

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

    9.8.2009 01:15 kolemjdouci
    Rozbalit Rozbalit vše Re: Tvrdý náraz do měkkých aktualizací

    asi kvuli tomu nebudu spat !

    Josef Kufner avatar 7.8.2009 09:55 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Tvrdý náraz do měkkých aktualizací
    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.
    Hello world ! Segmentation fault (core dumped)
    10.8.2009 12:57 j
    Rozbalit Rozbalit vše Re: Tvrdý náraz do měkkých aktualizací
    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.
    7.8.2009 10:19 Palo
    Rozbalit Rozbalit vše Re: Tvrdý náraz do měkkých aktualizací

    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.

    7.8.2009 11:30 Radek Černoch | skóre: 14 | Praha
    Rozbalit Rozbalit vše Re: Tvrdý náraz do měkkých aktualizací
    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í. ;-)
    7.8.2009 12:57 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Tvrdý náraz do měkkých aktualizací
    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č.
    Quando omni flunkus moritati
    7.8.2009 13:08 Radek Černoch | skóre: 14 | Praha
    Rozbalit Rozbalit vše Re: Tvrdý náraz do měkkých aktualizací
    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.

    7.8.2009 14:54 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Tvrdý náraz do měkkých aktualizací
    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.
    Quando omni flunkus moritati
    7.8.2009 15:12 Radek Černoch | skóre: 14 | Praha
    Rozbalit Rozbalit vše Re: Tvrdý náraz do měkkých aktualizací

    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?

    7.8.2009 15:11 Kvakor
    Rozbalit Rozbalit vše Re: Tvrdý náraz do měkkých aktualizací
    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.
    7.8.2009 18:26 Filip Jirsák | skóre: 67 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Tvrdý náraz do měkkých aktualizací
    Nebylo by jednodušší prostě to zapsat na ten disk?
    7.8.2009 22:56 Kvakor
    Rozbalit Rozbalit vše Re: Tvrdý náraz do měkkých aktualizací
    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 avatar 8.8.2009 10:08 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Tvrdý náraz do měkkých aktualizací
    No naštěstí informace o výpadku napájení dává už sám zdroj, který ty kondenzátory má dostatečně veliké.
    Hello world ! Segmentation fault (core dumped)
    8.8.2009 10:33 frr | skóre: 33
    Rozbalit Rozbalit vše Re: Tvrdý náraz do měkkých aktualizací

    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...

    [:wq]
    8.8.2009 10:57 Filip Jirsák | skóre: 67 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Tvrdý náraz do měkkých aktualizací
    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é.
    8.8.2009 11:44 8an | skóre: 30
    Rozbalit Rozbalit vše Re: Tvrdý náraz do měkkých aktualizací

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

    If you build an operating system that even an idiot can use, only idiots will use it.
    8.8.2009 12:13 Filip Jirsák | skóre: 67 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Tvrdý náraz do měkkých aktualizací
    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.
    8.8.2009 12:23 frr | skóre: 33
    Rozbalit Rozbalit vše Re: Tvrdý náraz do měkkých aktualizací

    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 :-D

    [:wq]
    10.8.2009 13:54 melkors | skóre: 13 | blog: kdo_chce_kam
    Rozbalit Rozbalit vše Re: Tvrdý náraz do měkkých aktualizací

    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.

    8.8.2009 13:28 graviton
    Rozbalit Rozbalit vše překlep (v originále mezitím opraveno)
    s/Yale Pratt/Yale Patt/

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.