Jaderné noviny – 14. 4. 2011: Úložné technologie budoucnosti

27. 4. 2011 | Jirka Bourek | Jaderné noviny | 4227×

Aktuální verze jádra: 2.6.39-rc3. Citáty týdne: Ryan Ware, Thomas Gleixner. Nativní nástroj pro KVM. LFCS: ARM, řídící skupiny a dalších 20 let. Linux a úložné technologie budoucnosti.

Obsah

• Aktuální verze jádra: 2.6.39-rc3
• Citáty týdne: Ryan Ware, Thomas Gleixner
• Nativní nástroj pro KVM
• LFCS: ARM, řídící skupiny a dalších 20 let
  • Řídící skupiny
  • Za dvacet let
• Linux a úložné technologie budoucnosti

Aktuální verze jádra: 2.6.39-rc3

Současné vývojové jádro je 2.6.39-rc3 vydané 11. dubna. Linus řekl:

Byl to další téměř strašidelně klidný týden. Takový klid obvykle nastává až mnohem později během série -rc (řekněme -rc7 či -rc8), ale nehodlám si stěžovat. Prostě jenom čekám na to, až dopadne druhá bota.

A je také možné, že tohle prostě bude velice klidný vývojový cyklus. Rozhodně jsme neměli žádné velké revoluční změny jako věci okolo vyhledávání jmen z minulého cyklu. Takže jsem tiše optimistický ohledně toho, že by druhá bota nemusela dopadnout vůbec.

Zkrácený changelog je v oznámení, všechny detaily vizte v kompletním changelogu.

Stabilní aktualizace: během tohoto týdne nevyšly žádné stabilní aktualizace. V době psaní tohoto článku se reviduje 2.6.38.3; očekávat ho lze někdy 14. dubna nebo později. Revidují se také 2.6.33.10 a 2.6.32.37, vydání se očekává 15. dubna nebo později.

Citáty týdne: Ryan Ware, Thomas Gleixner

Jestli použijeme referenční politiku SELinuxu, pak naprosto souhlasím. Nicméně podívat se na něco, co by se zaměřilo na řízení soukromí v SELinuxu, by složitost omezilo. Máš pravdu, že by bylo jednodušší vytvořit LSM, který by dělal přesně to, co potřebujeme. Jenže kvůli politice MeeGo by to znamenalo takový modul nejprve před použitím dostat do upstreamu a to by bylo problematické

-- Ryan Ware

Toto pole bude obsahovat informace o interním stavu a nebude vystaveno nikam mimo základní kód – kromě přístupu přes přístupové funkce. Už mě štve, jak si každý s irq_desc.status dělá, co chce.

vnitřní_interní_stav__nehrabte_na_to [core_internal_state__do_not_mess_with_it] je zcela srozumitelné, špatně se to píše a dobře grepuje. Kdo to použije, bude vypátrán a nafackuje se mu smrdícím pstruhem.

-- Thomas Gleixner

Nativní nástroj pro KVM

napsal Jonathan Corbet, 12. dubna 2011

Subsystém KVM poskytuje nativní podporu virtualizace v linuxovém jádře. Za tímto účelem nabízí virtualizované CPU a přístup do paměti, ale už ne o moc více; je zapotřebí další softwarovou komponentu, která poskytne virtuální verze veškerého hardware (konzole, disky, síťové adaptéry atd.), který jádro obvykle při bootu očekává. S KVM se obvykle používá emulátor QEMU, který tento hardware poskytne. I když je QEMU stabilní a dostatečně schopné, není všeobecně milováno; právě se objevil konkurent, který QEMU nemusí nahradit, ale možná si zabere část jeho uživatelů.

Před rokem a něco málo se Jaderné noviny zabývaly rozsáhlou diskuzí o KVM a konkrétně o verzi QEMU, kterou KVM používá. V dané době padaly návrhy, že by QEMU mělo být forkováno a přidáno do stromu zdrojových kódů jádra; cílem mělo být zrychlit vývoj a pružněji reagovat. K forku nedošlo a nápad zdánlivě zmizel.

Teď je zpátky v trochu odlišné formě, Pekka Enberg oznámil „nativní nástroj pro KVM“. Ve zkratce tento nástroj poskytne příkaz (nazvaný kvm), který může nahradit QEMU – tedy pokud nebudete mít zájem o většinu vlastností, které QEMU nabízí. Nativní nástroj je schopen nabootovat jádro, se kterým si lze povídat přes sériovou konzoli. Chybí mu podpora grafiky, síťování, SMP a mnoho dalšího, ale když ho spustíte v emulátoru terminálu, dostanete se k požadavku na přihlášení.

Proč je takový nástroj zajímavý? Je zde pár ne zcela kompatibilních důvodů. Nahrazení QEMU je hezký nápad, protože, jak prohlásil Avi Kivity, je to hnusná hromada slizu. Kód kvm – protože je nový a nemá mnoho vlastnosti – je kompaktní, čistý a snadno se s nim pracuje. Někteří vývojáři řekli, že kvm zjednodušuje ladění (obzvláště co se problémů v počátečních fázích bootu týče), ale jiní pochybují, že by QEMU a jeho rozsáhlou emulaci hardware mohlo někdy nahradit. Také se mluvilo o tom posunout kvm k paravirtualizovanému modelu, aby se získala co nejlepší výkonnost, ale na druhou stranu je tu odpor udělat něco, co by znemožnilo boot nativních jader.

Vývojářům se podle všeho tento nápad líbí a je velká šance, že se někam dostane, i kdyby nikdy neměl ohrozit QEMU a odsunout ho stranou. Objevilo se několik stížností na jméno kvm – QEMU již nyní obsahuje příkaz kvm a toto jméno se už teď špatně hledá – v době psaní tohoto článku se nicméně neobjevila žádná alternativa. Bez ohledu na to tento projekt vypadá jako něco, co stojí za to sledovat; zjevně se jedná o nástroj, na kterém chtějí lidé pracovat.

LFCS: ARM, řídící skupiny a dalších 20 let

napsal Jake Edge, 13. dubna 2011

Nedávno se konal Linux Foundation Collaboration Summit (LFCS), jehož součástí byla i tradiční panelová diskuze o jádře, která se konala 6. dubna. Účastnili se Andrew Morton, Arnd Bergmann, James Bottomley a Thomas Gleixner a diskutovali o jádře s Jonathanem Corbetem, který se ujal role moderátora. Bylo pokryto mnoho témat, ale současné potíže v komunitě ARM byly zjevně na čelních příčkách toho, na co mysleli jak účastníci, tak obecenstvo.

Každý z hackerů jádra se představil, přičemž někteří to udělali s humorem, jako například James Bottomley, který prohlásil, že je tam proto, aby se setkal se slavnými vývojáři jádra; Andrew Morton řekl, že strávil nejvíce času snahou zjistit, co ostatní vývojáři provedli se subsystémem správy paměti. Arnd Bergmann byl trochu skromný, co se jeho příspěvků týče, takže Thomas Gleixner upozornil na to, že to byl Arnd, kdo udělal ten poslední kus práce potřebný k odstranění velkého jaderného zámku; následoval velký potlesk. Co se vlastní práce týče, Thomas byl trochu překvapen, když zjistil, že se stará o hlášení o chybách týkajících se NANA flash pamětí (alespoň podle překlepu na obrovských slidech na obou stranách pódia), nicméně poznamenal, že se specializuje na nemožné úkoly jako je dostat patche preempce v reálném čase v reálném čase do hlavní řady.

Jonathan chtěl, aby se panel nejprve zabýval vysokoúrovňovou záležitostí týkající se architektury, jednalo se o současné problémy ve světě ARM. Řekl, že je to jedna z našich významnějších architektur, bez které bychom si nemohli hrát se svými telefony s Androidem. Je tedy neradostné vidět, jaký je v ní bordel. Jaká je tedy situace, ptal se Jonathan, a jak ji můžeme zlepšit?

Dlouhou dobu bylo problémem ARM komunity přesvědčit výrobce systémů na čipu (system-on-chip, SoC) a desek, aby svůj kód zasílali do upstreamu, řekl Arnd, ale teď se objevil nový problém: všichni mají své podstromy, které moc dobře nespolupracují. Každý si jde svou cestou, což znamená, že základní kód a kód ovladačů se pětkrát nebo dvacetkrát kopíruje do různých stromů pro různé SoC.

Jonathan se zeptal, jestli jaderná komunita může s ohledem na ARM něco dělat lépe. Thomas řekl, že správce ARM Russell King se snaží tlačit zpátky špatný kód, ale jednoduše to nestíhá. Ve stromě ARM je 70 subarchitektur a 500 různých SoC. Krom toho, jak upozornil Arnd, lidé posílají stromy subarchitektur přímo Linusovi, takže Russel nad takovými nemá vůbec žádnou kontrolu. James Bottomley dodal, že je to důsledek napětí mezi čistotou kódu a časem do dodání na trh.

Thomas si myslí, že širší jaderná komunita by měla poskytnout výrobcům ARM správné abstrakce a protože chybí náhled, jak by mělo vše vypadat, nelze od výrobců očekávat, že by s nimi přišli sami. Větší část výrobců má odlišné myšlení, protože jsou zvyklí na operační systémy, kde nejsou změny v základním kódu možné, takže 500 řádků dlouhé workaroundy v ovladačích jsou běžnou věcí. Arnd řekl, že by kód výrobců měl být revidován a v upstreamu před dodáváním takových produktů na trh. Andrew Morton řekl, že by to měla být cena za přijetí, na kterou by měli výrobci přistoupit a horizontálně udržovat jednotlivé kusy kódu v ARM stromech. Nicméně skutečně je k tomu motivovat je těžké.

Z publika se Wolfram Sang zeptal, jestli by pomohlo víc revizí patchů ARM. Všichni se shodli na tom, že revize kódu jsou dobré, ale Arnd byl trochu rezervovaný, protože obecně je jenom pár revidovatelů, kterým může správce subsystému důvěřovat, že si všimnou důležitých problémů, takže ne všechny revize kódu byly stvořeny jako sobě rovné. Andrew navrhl ekonomiku revidování, kde by jeden zasilatel patchů musel revidovat patche jiného a opačně. To by vývojářům umožnilo před svými nadřízenými ospravedlnit čas strávený revizemi kódu. Arnd na to odpověděl, že spolupráce s konkurencí je pro organizace, které jsou nováčky v open source vývoji, složitým konceptem.

Pokud ovladač vypadá jako něco, co již je ve stromě, neměl by být začleněn, ale místo toho by vývojáři měli být tlačeni k tomu pracovat s existujícím ovladačem, řekl Arnd. Thomas dodal, že v SoC se opakovaně používají stejné IP bloky, ale vývojáři si toho nejsou vědomi, protože na různých SoC pracují různé týmy. Jaderná komunita potřebuje lidi, kteří na toto přijdou. James řekl, že první otázkou by mělo být: nedělal to někdo již dříve a můžu to ukrást?

V reakci na otázku z publika na názory ohledně Linaro Arnd Bergmann, který u nich pracuje, s úsměvem odpověděl: Já myslím, že jsou skvělí. Potom pokračoval tím, že Linaro pracuje na něčem, co je úzce spojené s problémy ARM, které byly diskutovány. Zajistit, aby různí výrobci SoC spolupracovali, je velkou součástí toho, co Linaro dělá, a pokud k této spolupráci nedojde, trpět budou všichni. ARM je jedno z míst, kde je spolupráce zapotřebí nejvíc, dodal.

Řídící skupiny

Diskuze se brzy přesunula k řídícím skupinám, přičemž Jonathan podotkl, že čím dál tím víc prostupují jádrem, ale spousta jaderných vývojářů je nenávidí. Brzy bude složité nabootovat a provozovat distribuce bez řídících skupin, řekl a položil otázku, jestli jejich přidání do jádra bylo správným krokem: Neudělali jsme chybu? Thomas Gleixner odpověděl, že konceptuálně není na řídících skupinách nic špatného, ale kód je děsivý. James Bottomley si stěžoval na kód, který je roubován na řídící skupiny, protože každý zdroj v jádře, který je řízen, musí poměrně rušivě zasahovat do více subsystémů.

Jako všechno, co v jádře stojí za prd, i řídící skupiny je potřeba pročistit a musí to udělat někdo, kdo se na ně podívá z globální perspektivy; taková osoba je bude muset reimplementovat a radikálně upravit, míní Thomas. James opáčil, že to bude složité, protože jde jak o technický problém, tak o problém politický. Technický problém je zajistit, aby interakce fungovaly dobře, politická část je, že je problémem provádět v jádře změny přesahující hranice susbystémů.

Andrew Morton ale řekl, že neviděl moc specifických stížností na řídící skupiny. Konceptuálně rozšiřují to, co by operační systém měl dělat ohledně omezování zdrojů. Jestli je v nich bordel, je to kvůli způsobu, jakým byly vyvinuty nad produkčním jádrem, které se aktualizuje každé tři měsíce. James řekl, že problémem práce na něčem mezi subsytémy je často pouhou záležitostí komunikace, také to ale vyžaduje někoho, kdo by převzal vlastnictví a mluvil za všechny relevantní subsystémy, a ne jenom vybral nejslabší subsystém, přes který se změny začlení.

Jonathan položil otázku, jestli se mění nezávislost subsystémů v jádře, která doteď byla velmi užitečná a umožnila škálování vývoje. Účastníci diskuze si podle všeho myslí, že zde není žádný problém. James upozornil, že i když řídící skupiny překročily hodně hranic, vyjmenovat dalších pět podobných věcí by u jádra bylo složité.

Za dvacet let

Vzhledem k tomu, že se letos slaví dvacáté výročí Linuxu, zeptal se Jon Masters z publika, jak budou věci vypadat za dvacet let. James rychle odpověděl, že čtyři pětiny účastníků panelu budou v důchodu, ale Thomas Gleixner očekává, že chyba roku 2038 je všechny z důchodu zase vytáhne. Andrew Morton řekl, že pokud nějaký kvantový počítač nezpůsobí, že by Linux zastaral, za dvacet let tu stále bude. Také očekává, že první věcí, která se u kvantových počítačů udělá, bude emulační vrstva pro x86.

Když Jonathan řekl, že předpokládá, že tou dobou by již mohl být začleněn kód pro realtime preempci, vyslovil Thomas doposud nejpřesnější odhad, kdy bude kód začleněn: Plánuju to dodělat, než půjdu do důchodu. Na vážnější notu řekl, že je to na dobré cestě, mluvil s relevantními správci subsystémů a je optimistou v tom, že to bude začleněno – jednou.

Za dvacet let bude jádro stále podporovat existující rozhraní pro uživatelský prostor, řekl Jonathan. Citoval Andrewův nedávný příspěvek z jaderné mailové konference – Naším kladivem jsou patche do jádra a všechny problémy vypadají jako hřebíky – a položil otázku, jestli je problém v tom, jak vývojáři jádra vyvíjí rozhraní do uživatelského prostoru. Andrew řekl, že citát se týkal dalšího hezkého vypisování v jádře, čemuž obvykle oponuje. V minulosti se to dělalo, protože pro jaderné vývojáře je těžké dodávat kód pro uživatelský prostor, který by zůstával synchronní se změnami jádra. Perf nicméně předvedl, že jádro může dodávat kód pro uživatelský prostor, což by byla správná cesta kupředu.

Thomas poznamenal, že proti dodávání perfu byl poměrně velký odpor, ale fungovalo to poměrně dobře jako způsob, jak udržet striktní spojení mezi jádrem a uživatelským prostorem. Perf je míněn jako jednoduchý nástroj, který má uživatelům umožnit sběr událostí výkonnosti [perf events], přičemž lidé nad ním staví složitější nástroje. Dodávání nástrojů s jádrem poskytuje větší svobodu pro experimenty s ABI, řekl James. Andrew odpověděl, že je potřeba najít střední cestu, a poznamenal, že Google má patch, který do procfs exportuje soubor obsahující shellový skript.

Ingo Molnár nedávno upozornil, že FreeBSD má kvalitu odpovídající Linuxu s mnohem menší komunitou vývojářů, a nadhodil, že to může být tím, že se uživatelský prostor a jádro vyvíjí společně. Jonathan položil otázku, jestli se Linux nebrzdí tím, že po této cestě nejde. James si myslí, že Ingo má i nemá pravdu a že FreeBSD obsahuje celou distribuci ve stromě zdrojových kódů jádra. Doufám, že k tomu se Linux nikdy nedostane, řekl.

Od perfu k řídícím skupinám, od ARMu k FreeBSD, jako vždycky se panelová diskuze v přidělené hodině věnovala mnoha tématům. Formát i účastníci se rok od roku mění, ale je vždy zajímavé slyšet, co si jaderní vývojáři myslí o problémech, kterým Linux čelí.

Linux a úložné technologie budoucnosti

napsal Jonathan Corbet, 6. dubna 2011

Otevírající plenární diskuzi druhého dne Linux Filesystem, Storage, and Memory Management workshopu 2011 vedl Michael Cornwall, globální ředitel pro technologické standardy v IDEMA, organizaci vytvářející standardy pro výrobce disků. Před třinácti lety, když pracoval pro výrobce hardwaru, měl Michael problémy s tím najít správnou osobu, se kterou v linuxové komunitě pracovat, aby hardware jeho firmy získal podporu v Linuxu. O roky později tento problém stále přetrvává; pro hardwarový průmysl není jednoduché pracovat s linuxovou komunitou a důsledkem je to, že komunita má mnohem menší vliv, než by měla mít. Jeho přednáška se zabývala změnami, které se v průmyslu úložných zařízení chystají, a jak se má komunita zapojit, aby pro ni věci fungovaly lépe.

IDEMA (International Disk Drive Equipment and Materials Association) standardizuje disky a mnoho komponent v nich. I když někteří by řekli, že diskové jednotky – rotující úložiště – odcházejí, faktem je, že průmysl loni dodal rekordních 650 milionů disků a v roce 2015 se jich chystá dodat miliardu. To rozhodně není průmysl, který brzy zmizí. Kdo tento průmysl řídí? Podle Michaela jsou čtyři firmy, které řídí směr, kam se průmysl rotujících disků ubírá: Dell, Microsoft, HP a EMC. Tři z těchto firem dodávají Linux, ale při plánování Linux není reprezentován ani trochu.

Nejeden člověk by mohl být překvapen tím, co v současných discích najde. Typicky se tam nachází vícejádrový ARM procesor podobný těm, které lze nalézt v mobilních telefonech, a až 1GB RAM. ARM procesor sám o sobě toho zvládne hodně, ale i tak se mu dostává značné podpory od dedikovaného hardware; generování kódu pro kontrolu a opravování chyb, implementaci protokolu, správu bufferů, detekci sekvenčního I/O a další zajišťují samostatné obvody. Disky jsou malé počítače, na kterých běží poměrně schopný operační systém.

Programovací rozhraní disků se téměř dvě dekády téměř nezměnilo: disky stále nabízejí 512B dlouhé bloky náhodně adresovatelné logickými adresami. Největším problémem na straně software je co nejméně pohybovat hlavičkami disku. Hardware během let značně pokročil, ale stále je zaseklý u „archaické programovací architektury“. Tato architektura se ale v budoucích letech bude muset změnit.

Jako první významná změna byl zmíněn „pokročilý formát“ – termín pro disky se sektory o velikosti 4k. Christoph Hellwig žádal o příležitost pohovořit si s tou osobou od marketingu, která tenhle termín vymyslela; my ostatní můžeme jenom doufat, že tato konverzace proběhne ve veřejné konferenci, abychom se mohli dívat. Motivací přechodu na sektory o velikosti 4k je větší efektivita kódu pro opravu chyb [error-correcting code, ECC]. Tím, že se pomocí ECC budou chránit větší sektory, lze získat nějakých 20% kapacity navíc.

Vývojář, který odvedl největší práci na tom, aby disky s 4k sektory fungovaly v Linuxu, je Martin Petersen; ten si stěžoval, že je téměř nemožné spolupracovat s průmyslem na nových technologiích. Prototypy od výrobců v Linuxu fungovaly, ale první produkční disky, které se objevily, nefungovaly vůbec. A i se svým „800 librovým kloboukem od Oracle“ jenom těžko získával reakce na problémy. „Vítejte do obchodu s pevnými disky,“ odpověděl Michael. Pak řekl, že je potřeba vytvořit pro hardware program „certifikováno pro Linux“, což pravděpodobně bude muset udělat Red Hat, aby to někdo v průmyslu bral vážně. Ostatní s tímto nápadem souhlasili a dodali, že aby tento program byl opravdu efektivní, výrobci jako Dell a HP musí začít požadovat certifikaci pro Linux od dodavatelů.

Kromě většího sektoru přinášejí disky s 4k sektory mnoho jiných zajímavých problémů. Ve výchozím nastavení Windows 2000 správně nezarovnávají oddíly, takže někteří výrobci vytvořili disky s posunutým zarovnáním, aby to vykompenzovali. Další zůstali u normálního zarovnání a není vždy jednoduché tyto dva typy disků odlišit. V reakci na požadavky Microsoftu a Dellu výrobci také začali dodávat nativní 4k disky, které vůbec neemulují sektory o velikosti 512B – je tu tedy široká škála hardwaru, se kterým je potřeba se vypořádat. Pro vývojáře, kteří by chtěli pracovat s novějšími disky, je k dispozici testovací souprava.

Dalším krokem jsou podle všeho „hybridní disky“, které kombinují rotující úložiště a flash v jednom balení. První generaci těchto disků se na trhu nevedlo příliš dobře; Windows zjevně přebraly kontrolu nad flash pamětí v disku a tak jí zabránily plnit původní účel, takže nedošlo k žádnému navýšení výkonnosti. Přichází druhá generace, které by se mohlo vést lépe; tyto disky mají větší flash úložiště (od 8 po 64GB) a neumožňují operačnímu systému se v něm hrabat, takže by měly fungovat dobře.

Ted Ts'o měl obavy z toho, že tyto disky by mohly být optimalizovány pro souborové systémy jako VFAT a NTFS; takové optimalizace většinou nefungují dobře, když se používají jiné souborové systémy. Michael odpověděl, že to je součástí většího problému: linuxové souborové systémy jsou pro výrobce neviditelné. Pokud by měli důvod podporovat ext4 nebo btrfs, výrobci by to udělali; pro disk je to konec konců jednoduchá záležitost pohledu na tabulku rozdělení a zjištění, s jakými souborovými systémy má tu čest. Výrobci ale nemají tušení, jaká poptávka může existovat pro specifické souborové systémy v Linuxu, takže tato podpora nebude.

V ještě o něco vzdálenější budoucnosti nás čeká „šindelový magnetický zápis“ [shingled magnetic recording, SMR]. Tato technologie odstraňuje běžné ochranné mezery mezi sousedícími stopami na disku, což vede na dalších 20% navýšení kapacity. Tyto ochranné mezery bohužel existují z nějakého důvodu: umožňují zapsat jednu stopu bez poškození jiné. SMR disk tedy nemůže přepsat jenom jednu stopu; musí přepsat všechny v jednom šindelu. To znamená, řekl Michael, že velké sekvenční zápisy by „měly mít rozumnou výkonnost“, zatímco malé náhodné se mohou chovat velice špatně.

Průmysl se stále snaží přijít na to, jak zajistit, aby SMR fungovalo dobře. Jednou z možností je vytvořit na disku dvě oblasti – jednu s šindely, druhou bez nich. Všechny zápisy by se nejprve uložily do oblasti bez šindelů a pak na pozadí přepsaly do šindelů. To by vynutilo přidat mapovací tabulku, do které by se uložilo skutečné umístění každého bloku. Tento nápad vyvolal u publika obavy: jak by bylo možné optimalizovat I/O přístupy, když by zmizelo spojení mezi logickou adresou bloku a jeho umístěním na disku?

Odpovědí je podle všeho to, že by při přepisu disk data uložil v přirozené podobě (nebo něčem, co by se jí podobalo) a defragmentoval je. Celý tento proces by závisel na tom, že disk bude mít dostatek času nečinnosti, kdy by se mohl věnovat přepisování; většina disků je nečinná 90 % času, takže to by neměl být problém. Práce v cloudu a virtualizace by to ale mohly ztížit; účelem těchto technologií je koneckonců maximalizace využívání hardwaru. Výrobci disků si ale podle všeho myslí, že to bude fungovat.

Michael prezentoval čtyři různé varianty pro programovací rozhraní SMR disků. Prvním byla tradiční emulace s remapováním, která byla popsána výše; takové disky budou fungovat všude, ale mohly by mít problémy s výkonem. Další možností jsou „SMR s velkými bloky“ [large block SMR] – disky, které by všechny přenosy prováděly po velkých blocích, například 32MB naráz. Takové disky by nebyly vhodné pro všechny účely, ale co se záznamu videa či zálohování týče, tam by mohly být dobré. Další možností je „emulace s nápovědou“ [emulation with hints], která by operačnímu systému umožnila specifikovat, které bloky by měly být na fyzickém disku umístěny vedle sebe. A pak je tu kompletní přístup s ukládáním objektů, kde disk ví o logických objektech (souborech) a snaží se je uložit spojitě.

Jak dobře budou tyto disky fungovat v Linuxu? Těžko říci; v současnosti v technologické komisi nereprezentuje Linux nikdo. Tyto disky mají na trh dorazit roku 2012 či 2013, takže nyní je čas ovlivnit jejich vývoj. Komise je prý relativně otevřená, má otevřené mailové konference, nejsou potřeba žádné dohody o utajení a žádné utlačující požadavky na licencování patentů, takže by pro linuxové vývojáře nemělo být těžké se účastnit.

Kromě SMR je tu koncept nonvolatilní RAM (NV-RAM). NV-RAM zařízení je pole tradičních dynamických RAM modulů, stejně velkých flash a na desce je spousta kondenzátorů. Při běžné práci se používá normální RAM, ale když selže napájení, náboj v kondenzátorech se využije k k překopírování dat z RAM do flash; tato data se obnoví s obnovením napájení. High-endové úložné systémy NV-RAM používají již nějaký pátek, ale tato zařízení se postupně mění v běžný produkt cílený na větší trh.

NV-RAM zařízení se v současnosti dodává ve třech podobách. První vypadá jako tradiční rotující disk, druhá je karta do PCI-Express se samostatným blokovým ovladačem a třetí je NV-DIMM, která se připojuje přímo na paměťovou sběrnici systému. NV-DIMM mají největší potenciál, ale také je nejtěžší je podporovat; například vyžadují BIOS, který je rozpozná, nezlikviduje jejich obsah testem paměti při startu a nerozloží řádky cache mezi NV-DIMM zařízení a běžnou paměť. Nejedná se tedy o něco, co by se jen tak dalo zapíchnout do každého počítače.

Co se týče ještě vzdálenější budoucnosti, skutečné nonvolatilní paměti přijdou někdy kolem roku 2015. Jak s k nim budeme připojovat a jak zajistíme, aby jejich architektura byla správná? Dell a Microsoft požádali o nativní 4k sektory a dostali je. Co chce linuxová komunita? Michael doporučil, aby lidé kolem jádra sestavili pětičlenný tým, který by se bavil s výrobci. Také by měl existovat seznam vývojářů, kteří by měli dostávat vzorky hardwaru. A co je důležité, měli bychom mít dobře zformovaný názor na to, co chceme. S tím by průmysl mohl začít linuxové komunitě naslouchat a to by bylo jedině dobře.

       

Komentáře

[Saljack]

Ten druhy citat me pobavil

[Luboš Doležel (Doli)]

Opravdu nemá chybu

[yac]

Obzvlášť zábavný díl, díky.

[Petr Ježek]

Ehm, kromě srandy by tu byla i letitá páchnoucí treska obtížné komunikace mezi HW komercí a lidmi kolem GNU/Linuxu. To je totiž o zodpovědnosti a do toho se mnoha takytučňákistům moc nechce... Rád bych poznal někoho z českých luhů a hájů, kdo by se ujal reprezentace linuxu před HW světem tak, aby Michael nemusel plédovat...