Podpora Windows 10 končí 14. října 2025. Připravovaná kampaň Konec desítek (End of 10) může uživatelům pomoci s přechodem na Linux.
Již tuto středu proběhne 50. Virtuální Bastlírna, tedy dle římského číslování L. Bude L značit velikost, tedy více diskutujících než obvykle, či délku, neboť díky svátku lze diskutovat dlouho do noci? Bude i příští Virtuální Bastlírna virtuální nebo reálná? Nejen to se dozvíte, když dorazíte na diskuzní večer o elektronice, softwaru, ale technice obecně, který si můžete představit jako virtuální posezení u piva spojené s učenou
… více »Český statistický úřad rozšiřuje Statistický geoportál o Datový portál GIS s otevřenými geografickými daty. Ten umožňuje stahování datových sad podle potřeb uživatelů i jejich prohlížení v mapě a přináší nové možnosti v oblasti analýzy a využití statistických dat.
Kevin Lin zkouší využívat chytré brýle Mentra při hraní na piano. Vytváří aplikaci AugmentedChords, pomocí které si do brýlí posílá notový zápis (YouTube). Uvnitř brýlí běží AugmentOS (GitHub), tj. open source operační systém pro chytré brýle.
Jarní konference EurOpen.cz 2025 proběhne 26. až 28. května v Brandýse nad Labem. Věnována je programovacím jazykům, vývoji softwaru a programovacím technikám.
Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Před 25 lety zaplavil celý svět virus ILOVEYOU. Virus se šířil e-mailem, jenž nesl přílohu s názvem I Love You. Příjemci, zvědavému, kdo se do něj zamiloval, pak program spuštěný otevřením přílohy načetl z adresáře e-mailové adresy a na ně pak „milostný vzkaz“ poslal dál. Škody vznikaly jak zahlcením e-mailových serverů, tak i druhou činností viru, kterou bylo přemazání souborů uložených v napadeném počítači.
Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).
Tento článek je překladem z anglického originálu, a proto vychází se zpožděním.
Současné vývojové jádro je 2.6.28-rc3, vydané 2. listopadu. Obsahuje obvyklou hromádku oprav, odstraňuje (nyní nepoužívané) VFS metody prepare_write() a commit_write() a přidává nové ovladače pro touchpady Elantech (EeePC) a paměťové řadiče Intel X38.
Také byla začleněna změna API ovladačů; ovladače, které podporují FASYNC, již nemusí při uvolňování volat fasync_helper().
V době psaní tohoto článku bylo po -rc3 do repozitáře hlavní řady začleněno pár tuctů patchů. Společně s opravami je mezi nimi nové API mapování I/O paměti pro grafické ovladače; detaily vizte v článku níže.
O souborovém systému btrfs se široce předpokládá, že se v budoucnu stane preferovanou volbou pro Linux. Nicméně, co když jde btrfs špatným směrem a zbrojí na již dobojovanou válku? Jestliže se povaha našich úložných zařízení významně změní, naše souborové systémy se budou také muset změnit. Mnoho pozornosti je věnováno širokému rozšíření zařízení založených na flash, nicméně je zde další nadcházející technologie, pro kterou by se mělo plánovat: zařízení ukládající objekty [object storage device, OSD]. Nedávné zaslání nového souborového systému nazvaného osdfs poskytuje dobrou příležitost podívat se na OSD a na to, jak by mohla být podporována v Linuxu.
Vývojáři OSD zastávají názor, že tradiční na blocích založené diskové jednotky nabízejí příliš nízkoúrovňové rozhraní. Se současným hardwarem by mělo být možné natlačit do úložných zařízení více inteligence, zbavit hostitele zátěže při zachování (nebo zlepšení) výkonnosti a bezpečnosti. Rozhraní nabízené OSD tedy nepracuje s bloky; místo toho poskytuje hostitelskému systému "objekty". Většina objektů budou jednoduše soubory, ale podporováno je několik dalších typů objektů (oddíly například). Hostitel s těmito objekty manipuluje, ale nemusí (a nemůže) se zabývat tím, jak jsou tyto objekty implementovány v zařízení.
Objekt soubor je identifikován dvěma 64bitovými čísly. Obsahuje jakákoliv data, která si tam ten, kdo ho vytváří, přeje dát; OSD data nijak neinterpretuje. Soubory také mají sadu atributů a metadat; ty zahrnují většinu informací uložených v inodu na disku u tradičního souborového systému kromě informací o rozvržení bloků, které OSD před zbytkem světa skrývá. Se soubory lze provádět všechny obvyklé operace - čtení, zápis, prodlužování, zkracování, atd. - implementace těchto operací je nicméně opět zařízena samotným OSD.
Jednou z věcí, kterou OSD nezajišťuje, je vytváření adresářové struktury nebo pojmenovávání souborů. Od souborových systémů hostitele se očekává, že použije souborové objekty a svou adresářovou strukturu v nich uloží, aby uživatelům souborového systému poskytl použitelné rozhraní. OSD by se také pravděpodobně dalo použít jako určitý druh hardwarově implementované objektové databáze bez velkého množství vysokoúrovňového kódu, nicméně na to se nyní práce na OSD nezaměřuje.
OSD protokol [PDF] je rozšíření SCSI protokolu posvěcené T10. Očekává se tedy, že OSD zařízení budou přímo připojena k hostitelskému systému; protokol byl navržen tak, aby se v tomto režimu choval dobře. Také se ale očekává, že OSD se budou používat v prostředí síťových úložných zařízení. Kvůli takovým nasazením se vývojáři OSD rozhodli odsunout z hostitelského systému ještě jeden úkol: bezpečnost. Za tímto účelem obsahuje protokol OSD rozsáhlou sadu se zabezpečením spojených příkazů. Každá operace s objektem musí být doprovázena "kvalifikací", kryptograficky podepsaným potvrzením [ticket], které vyjmenovává objekt a přístupová práva, která má vlastník kvalifikace. Není-li vhodná kvalifikace přítomna, disk přístup znemožní.
Očekává se, že kvalifikace budou vydávány démonem bezpečnostní politiky, který poběží někde na síti. Démon může vlastnit kořenový klíč [root key] disku, který umožní neomezený přístup k disku, nebo může mít oddělený klíč pouze pro oddíl. Tak jako tak může daný klíč použít k podepsání kvalifikací jinde v systému. (Disky také mají "master" klíč, který se primárně používá pro změnu kořenového klíče. Ztráta master klíče je pravděpodobně událost typu "obnova ze zálohy").
Kvalifikace vydrží nějakou dobu (obsahují dobu platnosti) a popisují všechny povolené operace. Skutečné získávání kvalifikace by tedy mělo být relativně vzácné; většina OSD operací se bude provádět s využitím kvalifikací, které již systém má v ruce. To je důležitá vlastnost návrhu; přidání "požádej démona o kvalifikaci" do cesty I/O souborového systému by nebyl krok, který zlepší výkonnost.
Teoreticky by mělo být relativně jednoduché vytvořit standardní linuxový souborový systém s podporou OSD. Je to z větší části záležitost vyházení většiny nízkoúrovňového kódu správy rozvržení bloků a inodů a jeho nahrazení vhodnými operacemi s objekty. Souborový systém byl tímto způsobem vytvořen; vývojáři začali s ext2. Po odstranění veškerého kódu, který již nepotřebovali, jednoduše přidali kód, který překládá požadavky z úrovně VFS na operace, kterým OSD porozumí. Tyto požadavky jsou poté vykonány prostřednictvím nízkoúrovňového kódu osd iniciátor (který byl také nedávno zaslán ke zvážení). Adresáře jsou implementovány jako jednoduché soubory obsahující jména a s nimi spojená ID objektů. Na disku není žádný oddělený inode; všechny informace jsou uloženy jako atributy samotného souboru. Výsledkem je, že je kód osdfs relativně malý; převážně se zabývá mapováním VFS operací na OSD operace.
Každý, kdo by chtěl kód testovat, může narazit na jeden malý problém: v běžném obchodě s počítači se moc zařízení ukládajících objekty nenajde. Zdá se, že většina vývojové práce byla zatím udělána s použitím simulátorů těchto zařízení. OSC softwarový OSD je, stejně jako osdfs, součástí projektu open-osd; implementuje OSD protokol nad databází SQLite. Je k dispozici také OSD simulátor hostovaný u IBM, ale zdá se, že se v současnosti nevyvíjí. Na simulátorech založený vývoj a testování nemusí být tak uspokojující jako mít lesklé nové zařízení implementující OSD hardwarově, ale pomůže zajistit, aby jak software, tak protokol byly v dobrém stavu v době, kdy bude hardware k dispozici.
Je třeba poznamenat, že úspěch zařízení ukládajících objekty není zcela zaručen. OSD přebírá mnoho práce, kterou obvykle zajišťuje jádro operačního systému, a přehazuje ji do blobu firmwaru, který nelze prozkoumat ani opravit. Špatná implementace bude mít přinejlepším mizerný výkon; přinejhorším se může značně zvýšit pravděpodobnost ztráty dat. Může se ukázat, že nejlepší je trvat na tom, aby se úložná zařízení zabývala pouhým ukládáním bitů tam, kam jim operační systém řekne, a nechala vysokoúrovňová rozhodnutí na vysokoúrovňovém kódu. Nebo se může ukázat, že jsou OSD další krok kupředu k chytřejšímu, schopnějšímu hardwaru. Tak jako tak je to zajímavý experiment.
Více informací o tom, jak OSD funguje, vizte v tomto článku od Sunu.
Ve starých zlatých časech ovladače grafických karet pracovaly v uživatelském prostoru a jádro mělo s videopamětí málo co do činění. V nedávné době vývojáři grafiky rozhodně hlasovali pro změnu a při jejím provádění přesunuli správu videopaměti do jádra. Nyní tedy musí jádro často manipulovat s videopamětí přímo. A jak se ukazuje, je to těžší, než by se dalo očekávat - minimálně na 32bitových strojích, pokud uživateli záleží na rozumné výkonnosti.
Problém je v tom, že 32bitové stroje mají pouhé 4GB virtuálního adresového prostoru. Linux (obvykle) dělí tento prostor na dvě části; spodní 3 GB jsou dány uživatelskému prostoru, zatímco jádro samo zabere horní 1 GB. Rozdělení prostoru tímto způsobem má důležitý přínos: není nutné přizpůsobovat konfiguraci správy paměti při přechodu mezi jaderným a uživatelským prostorem, což věci významně zrychluje. Nevýhodou je, že jádro se musí vejít do tohoto zbývajícího gigabytu paměti. Ani se současnými jádry se to nezdá být takový problém, ale vzpomeňme na jednu věc: jádro potřebuje namapovat fyzickou paměť do svého adresového prostoru předtím, než s ní může cokoliv dělat. Velikost virtuálního adresového prostoru daného jádru tedy omezuje množství fyzické paměti, se kterou se dá přímo manipulovat.
Další věc, která se musí vejít do adresového prostoru jádra, je oblast vmalloc() - rozsah adres, které lze za běhu přiřadit, aby se v jádře vytvořila potřebná mapování. Když je virtuálně spojitý rozsah paměti alokován pomocí vmalloc(), mapuje se do tohoto rozsahu. Dalším uživatelem tohoto adresového prostoru je ioremap(), který zpřístupní rozsah I/O paměti jádru.
Ovladače zařízení typicky potřebují přístup k I/O paměti, takže použijí ioremap(), aby ji namapovaly do adresového prostoru jádra. Grafické adaptéry jsou nicméně trochu odlišné, protože mají velké oblasti I/O paměti: celou videopaměť. Současné grafické karty mají tak velkou videopaměť, že ioremap() by k mapování potřeboval příliš mnoho adresového prostoru, pokud by se do něj vůbec vešel. Přímé ioremap() je tudíž nepoužitelné; život byl mnohem jednodušší v těch zlatých časech, když byla I/O paměť mapována do uživatelského prostoru.
Vývojáři Intel i915, kteří jsou, co se týče správy GPU paměti založené na jádře, nejdál, na tento problém narazili první. Jejich počátečním řešením bylo mapování jednotlivých stránek pomocí ioremap() podle potřeby (přesněji pomocí ioremap_wc(), které zapne kombinování zápisu - detaily najdete v článku Učíme se zacházet s cachováním) a jejich následným odmapováním. Toto řešení funguje, ale je pomalé. Mezi jinými věcmi vyžaduje operace ioremap() meziprocesorové přerušení, aby se zajistilo, že budou všechna CPU vědět o změně adresového prostoru. Je to funkce navržená k tomu, aby se volala výjimečně a mimo kód kritický pro výkonnost. Udělat z volání ioremap() část běžných grafických operací není způsob, jak získat uspokojivý zážitek ve střílečkách.
Skutečné řešení přichází ve formě nového API mapování, které vyvinul Keith Packard (a následně vyladil Ingo Molnár). To hodně těží z faktu, že Linux musel řešit tento problém již dříve. Vzpomeňme, že jádro má (na 32bitových systémech) pouze 1 GB adresového prostoru, se kterým může pracovat; to je maximální množství fyzické paměti, které lze naráz přímo namapovat. Jakákoliv fyzická paměť nad tímto množstvím je nazvána "horní paměť"; normálně v adresovém prostoru jádra není mapována. Přístup k této paměti vyžaduje explicitní mapování pomocí kmap() nebo kmap_atomic(). Použití horní paměti je tedy složitější, ale tento trik umožnil 32bitovým systémům podporovat mnohem více paměti, než bylo předtím považováno za možné.
Nové API mapování čerpá z obsluhy horní paměti více než inspiraci - používá stejné mechanismy. Ovladač, který potřebuje mapovat velkou I/O oblast, nastaví mapování voláním:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
struct io_mapping *io_mapping_create_wc(unsigned long base,
unsigned long size);
Funkce vrací ukazatel na struct io_mapping, ale ve skutečnosti nemapuje žádnou I/O paměť do adresového prostoru jádra. To je potřeba provést po jednotlivých stránkách voláním jedné z funkcí:
void *io_mapping_map_atomic_wc(struct io_mapping *mapping,
unsigned long offset);
void *io_mapping_map_wc(struct io_mapping *mapping, unsigned long offset);
Každá funkce vrátí ukazatel do jaderného prostoru, který je mapován do stránky s daným offsetem. Atomická forma je v podstatě volání kmap_atomic() - používá slot KM_USER0, což je dobrá věc, o které by vývojáři měli vědět. Je z těch dvou podstatně rychlejší, ale vyžaduje, aby bylo mapování drženo v atomickém kódu a tímto způsobem lze namapovat pouze jednu stránku naráz. Kód, který by mohl spát, musí použít io_mapping_map_wc(), což se v současnosti vrátí ke staré implementaci ioremap_wc().
Mapované stránky lze samozřejmě odmapovat, pokud již nejsou zapotřebí:
void io_mapping_unmap_atomic(void *vaddr); void io_mapping_unmap(void *vaddr);
Tato implementace má několik zajímavých aspektů. Jedním je, že struct io_mapping ve skutečnosti není nikde definován. Kód si nepotřebuje pamatovat nic jiného než základní adresu, návratová hodnota z io_mapping_create_wc() je tedy ukazatel base, který byl předán. Druhým je, že tato struktura je ve skutečnosti potřeba pouze na 32bitových systémech; 64bitový procesor nemá problém s nalezením dostatečně velkého adresového prostoru, do kterého videopaměť mapovat. Na 64bitových systémech tedy prostě io_mapping_create_wc() namapuje celou oblast pomocí ioremap_wc(); operace s jednotlivými stránkami jsou no-opy.
Keith hlásí, že s touto změnou běží Quake 3 (používaný samozřejmě pouze k testovacím účelům) osmnáctkrát rychleji. Mnohem vážnější Dave Airlie testoval pomocí glxgears a dostal se ke zvýšení z 85 snímků za sekundu na 380. To je dost velké zlepšení na to, aby ten kód chtěli začlenit do 2.6.28, které bude obsahovat kód správce paměti GEM. Linus odpovídá:
Tento kód byl tedy začleněn do hlavní řady a objeví se v 2.6.28-rc4.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
4.12.2008 16:32
kozzi | skóre: 55
| blog: vse_o_vsem
| Pacman (Bratrušov)
se mi zdá že je hned na začátku chyba ve verzi aktuálního jádra 
4.12.2008 16:53
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
Kde najdu anglický originál? Nikde ho nemůžu najít.
To OSD me desi. Je to cisty marketing, zadnou realnou vyhodu to podle me neprinasi. Zkratka, je to blbost.
I kdybychom pripustili, ze firmware bude otevreny, k cemu to podle vas bude dobre? Bude to jen dalsi vrstva navic, ktera se bude muset konfigurovat, a ktera bude zdrojem nekompatibility. Takhle si nainstaluji Linux a vim, ze vevnitr jadra je vsechno kompatibilni. S OSD budeme resit, zda je dotycny firmware kompatibilni s prislusnou verzi operacniho systemu atd. Jak pak asi ten disk prenesu nekam jinam, kdyz kazdy system bude pozadovat jiny firmware disku?
Bude to jen dalsi vrstva navic, ktera se bude muset konfigurovat, a ktera bude zdrojem nekompatibility.Jaký nekompatibility? To rozhraní je jasně stanovené a zdrojem nekompatibility bude akorát v případě, že výrobce standard poruší (akorát v takovém případě jeho zařízení dost pravděpodobně nebude fungovat dobře a lidi si ho nebudou kupovat.) A s konfigurací to pravděpodobně bude podobné jako u ostatních disků.
S OSD budeme resit, zda je dotycny firmware kompatibilni s prislusnou verzi operacniho systemu atdStandard je jeden, tak jaká kompatibilita s příslušnou verzí?
Jak pak asi ten disk prenesu nekam jinam, kdyz kazdy system bude pozadovat jiny firmware disku?To je jako kdybys řekl, že SCSI disk nemůžeš nikam přenést, protože systém bude požadovat jiný firmware disku.
> Standard je jeden, tak jaká kompatibilita s příslušnou verzí?
Dobry vtip. Viz treba ACPI. V okamziku, kdy je rozhrani dostatecne slozite, tak zajistit rozumnou kompatibilitu mezi nezavislymi produkty, zvlaste pak v asymtericke situaci, je dost problem.
Protoze jsou jednoduche a slozite veci. SATA ci SCSI v zakladni variante je relativne jednoduche (ve srovnani treba s ACPI), proto neni takovy problem, aby to fungovalo. Pokud je protokol jednoduchy a vsichni ho pouzivaji tim spravnym zpusobem, tak spis problemy nenastanou. Pokud je protokol bohaty a nabizi cetne moznosti, tim spis to fungovat nebude a bude treba resit kompatibilitu. Pripadne bude trvat leta, nez se vychytaji problemy.
Pokud je protokol jednoduchy a vsichni ho pouzivaji tim spravnym zpusobem, tak spis problemy nenastanou. Pokud je protokol bohaty a nabizi cetne moznosti, tim spis to fungovat nebude a bude treba resit kompatibilitu.Já osobně si myslím, že problémy vznikají jenom tam, kde vznik problému neznamená pokles obratu výrobce.
Vyhoda OSD by mohla byt v prenositelnosti dat mezi platformami. Mohla. Teoreticky.
Jenze ja mluvil o situaci, kdy bude ten firmware otevreny a kazdy si ho bude moci menit podle sveho (coz jste predtim povazoval za zadouci). Pokud je uzavreny, jako treba u SCSI, tak moje namitka pada (ovsem soucasne nastupuji ty predtim).
Navic, jak rika Ondrej - SCSI je patrne pomerne jednoduche rozhrani ridici se cisly bloku. Tady maji byt nejake tokeny, sifrovani a ja nevim co jeste. Ten standard se bude vyvijet a menit, a nekompatibility tedy zakonite vzniknou.
A jeste jste mi neodpovedel na otazku, v cem vlastne spatrujete vyhody OSD?
Jenze ja mluvil o situaci, kdy bude ten firmware otevreny a kazdy si ho bude moci menit podle sveho (coz jste predtim povazoval za zadouci).Tak pozor - otevřený firmware, který si každý bude moci měnit podle svého, a dodržení protokolu jsou dvě různě věci. Pokud to převedu na současnou situaci, tak protokol je, že programy volají funkce jako je
open(), fread() a je jim jedno, jak to vypadá pod nimi, jestli jádro naváže síťové spojení s NFS serverem nebo začne číst z diskety. Implementace ext3 se může třikrát změnit, ale programu to bude jedno, protože open() stále bude otevírat soubor.
Stejně tak u OSD se může firmware měnit tím způsobem, že se například změní rozložení bloků souborů na disku, protože se ukáže, že novější varianta je efektivnější. V podstatě se může změnit cokoliv, co se v současných jádrech mění u souborových systémů. Podstatné je, že navenek ten firmware na požadavek na čtení souboru číslo 12345 vždy odpoví čtením souboru číslo 12345.
A jeste jste mi neodpovedel na otazku, v cem vlastne spatrujete vyhody OSD?Při dobré implementaci to znamená snížení zátěže hostitelského systému. V podstatě by šlo o akcelerátor diskových operací, kdy by se jádro nemuselo zabývat rozložením souborů na disku tak, jak to dělá dnes. Když se to vezme kolem a kolem, tak jednoduchá implementace by mohla být taková, že by na tom disku v podstatě klidně mohl být nějaký současný Linux - ten by se staral o ukládání dat třeba na ext4 a hostitelskému systému by poskytoval rozhraní OSD disku.
Ale do RAIDu už to asi nedám.
Myslím, že výhodné to může být u malých zařízení, jako jsou MP3playery či fotoaparáty, protože nebude třeba implementovat FS driver. Ale u osobních počítačů to moc určitě úspor výkonu nepřinese, ale přinese to určitě problémy s RAID a kompatibilitou a variabilitou.
8.12.2008 18:57
Stanislav Brabec | skóre: 45
| Praha
Návrh existuje právě proto, aby vyšší výkon přinesl. Dnešní operační systém vůbec netuší, kde jsou sektory fyzicky uloženy, takže nedokáže dělat vůbec žádné optimalizace s výjimkou jediné: "Sektory bezprostředně za sebou = rychlejší operace". Naproti tomu OSD by byl fyzicky vázán k disku a znal by jeho strukturu. To může přinést významný nárůst výkonu jak u rotujících, tak u flash disků.
A co víc: ESD by mohl měnit fyzickou strukturu dat v závislosti na typu zapisovaných dat. Například při zapisu video streamu by mohl nepřerušeně zapisovat do sektorů o délce celé stopy, při práci s fragmentovanými daty by je dokázal efektivněji uložit pro náhodný přístup.
RAID by s ESD zcela změnil implementaci. Zatímco dnes se ukládají sektory a kontrolní bloky, ESD RAID řadič by distribuoval objekty nebo kontrolní objekty, zatímco na vstupu by přijímal ESD objekty od OS.
To bych stále považoval za lepší, kdyby zařízení o sobě umělo říct první poslední, než tohle.
10.12.2008 13:15
Stanislav Brabec | skóre: 45
| Praha
To by vyžadovalo mnohem vyšší komplexitu OS. Zde jsou příklady z možných vstupů pro optimalizaci:
Nyní si představte, že nový fiktivní standard DiskDescription verze 1.0 vytvoří infrastrukturu, která to vše zvládne. Pak přijde další výrobce, který nabídne disk s nezávislým vystavováním hlaviček na plotnách, se dvěma hlavičkami nebo s možností paralelního čtení ze všech ploten, nebo třeba hybridní disk, který má nejčastěji čtená data ve flash paměti. DiskDescription verze 1.0 k popisu nebude stačit, a k podpoře nového zařízení bude potřeba aktualizovat všechny OS na DiskDescription verze 1.1, nebo se vrátit k neefektivnímu nepřůhlednému LBA režimu.
Pokud chcete mit jednoduchy OS, tak proste pouzijete cisla bloku a na rychlosti se vykaslete. Pokud chcete mit rychly pristup na disk optimalizovany podle organizace disku, pak dejte OS vsechny informace, a ten uz si to zaridi. Ale firmware disku neni od toho, aby resil specificke potreby jednotlivych aplikaci - od toho je OS, ktery se da snadno zmenit.
Naopak firmware ma resit specificky system rozlozeni na disku, a poskytovat rozhrani, ktere je co mozna nejrychlejsi a pritom jednoduche. Coz cisla bloku splnuji docela dobre (proto jsme na ne take presli od cylindru/sektoru/hlav, vzpominate?).
Vas priklad je zavadejici. Pokud se napriklad ve vasi aplikaci nespokojite s tim, ze za sebou jdouci bloky mohou skoncit na ruznych cylindrech (a budete chtit za sebou jdouci bloky s co mozna nejrychlejsim pristupem), budete muset zacit fyzickou vrstvu resit pres nejake vhodne rozhrani. Neni jina moznost. Ale OSD takove rozhrani neni - z toho, co jsem videl na tech strankach, mi nepripada, ze by v takovem pripade nejak pomohlo. Naopak se spis snazi delat veci, ktere by mel delat OS (jako sifrovani, partitioning, metadata).
10.12.2008 15:28
Stanislav Brabec | skóre: 45
| Praha
„Všechny informace o hardwaru“ je velmi povrchní pojem. Aby to fungovalo, musela by existovat rozsáhlá a komplexní norma, která by popisovala vlastnosti všech představitelných zařízení pro ukládání dat, a stejně komplikovaná implementace v OS. A přesto by se časem objevilo zařízení, na jehož popis nestačí.
Systém cylindrů/sektorů/hlav byl kdysi lepši než LBA. K systému LBA v kombinaci s falešnými cylindry/sektory/hlavami se přešlo kvůli omezením MS-DOSu. Systém, kdy OS a sběrnice používají LBA, HDD vnitřně používá fyzické sektory (nerovnoměrně rozmístěné po disku), a BIOS a tabulka partition používá (na BIOSu základní desky závislý) systém falešných rovnoměrně rozmístěných cylindrů/sektorů/hlav není ani rychlý, ani přímočarý. Oddíl tak třeba fyzicky začíná uprostřed stopy a nejrychleji se čte spolu s koncem předchozího oddílu.
Již dnes prostý systém LBA přestává stačit. Například nesmírně komplikuje implementaci zápisových bariér. Vysoce bezpečný FS musí zapsat žurnál, poté metadata a data, a nakonec vymazat žurnál. Fyzický zápis na plotny musí být proveden přesně v tomto pořadí, nestačí pouze odeslání do vyrovnávací paměti HDD. Často je jedinou cestou čekání na kompletní vyprázdnění vnitřni vyrovnávací paměti HDD, kdykoliv OS narazí na bariéru.
Přesun metadat do nižší vrstvy je logický krok. Hardware má k dispozici více informací o povaze zapisovaných dat (velké bloky, malé bloky, metadata) a může provádět daleko lepší optimalizaci.
Při dobré implementaci to znamená snížení zátěže hostitelského systému. V podstatě by šlo o akcelerátor diskových operací, kdy by se jádro nemuselo zabývat rozložením souborů na disku tak, jak to dělá dnes. Když se to vezme kolem a kolem, tak jednoduchá implementace by mohla být taková, že by na tom disku v podstatě klidně mohl být nějaký současný Linux - ten by se staral o ukládání dat třeba na ext4 a hostitelskému systému by poskytoval rozhraní OSD disku.
Akcelerator ma smysl tam, kde je jasne, ze problemu napomuze jine hardwarove usporadani nez pouzivaji soucasne procesory (tj. napriklad u grafiky, kde se pouzivaji vektorove/stream procesory, nebo u sifrovani apod.). V ostatnich pripadech je uzitecnejsi proste pridat dalsi obecny procesor, protoze softwarove reseni je nejenom praktictejsi, ale muzete ten procesor vyuzit i pro jine ucely nez I/O.
Je pravda, že ten procesor tam asi bude dost stejný, nicméně možná by se dalo právě tím že se dá jinam odlehčit některým sběrnicím, které jsou nyní úzkým hrdlem mnohem více než rychlost a množství procesorů. Ale spíš to asi nemá smysl.
Co ty no-opy ? To mam chapat jako instrukci NOP ?
9.12.2008 21:27
mov r0, r0, či niečo podobné).