Byla vydána nová verze 24.04.28 s kódovým názvem Time After Time svobodného multiplatformního video editoru Shotcut (Wikipedie) a nová verze 7.24.0 souvisejícího frameworku MLT Multimedia Framework. Nejnovější Shotcut je vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
Byla vydána verze 5.30 dnes již open source operačního systému RISC OS (Wikipedie).
V aktuálním příspěvku na blogu počítačové hry Factorio (Wikipedie) se vývojář s přezývkou raiguard rozepsal o podpoře Linuxu. Rozebírá problémy a výzvy jako přechod linuxových distribucí z X11 na Wayland, dekorace oken na straně klienta a GNOME, změna velikosti okna ve správci oken Sway, …
Rakudo (Wikipedie), tj. překladač programovacího jazyka Raku (Wikipedie), byl vydán ve verzi #171 (2024.04). Programovací jazyk Raku byl dříve znám pod názvem Perl 6.
Společnost Epic Games vydala verzi 5.4 svého proprietárního multiplatformního herního enginu Unreal Engine (Wikipedie). Podrobný přehled novinek v poznámkách k vydání.
Byl vydán Nextcloud Hub 8. Představení novinek tohoto open source cloudového řešení také na YouTube. Vypíchnout lze Nextcloud AI Assistant 2.0.
Vyšlo Pharo 12.0, programovací jazyk a vývojové prostředí s řadou pokročilých vlastností. Krom tradiční nadílky oprav přináší nový systém správy ladících bodů, nový způsob definice tříd, prostor pro objekty, které nemusí procházet GC a mnoho dalšího.
Microsoft zveřejnil na GitHubu zdrojové kódy MS-DOSu 4.0 pod licencí MIT. Ve stejném repozitáři se nacházejí i před lety zveřejněné zdrojové k kódy MS-DOSu 1.25 a 2.0.
Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Současné vývojové jádro je 2.6.30-rc1 vydané Linusem 8. dubna. Dvoutýdenní začleňovací okno se zavírá a dobře že tak, protože jsme měli spoustu změn. Jako vždycky. Rozhodně jsem neměl nutkání ponechat okno otevřené, aby se dovnitř dostalo těch posledních několik megabytů patchů. Významné změny v 2.6.30 budou zahrnovat architekturu správy integrity, bezpečnostní modul TOMOYO Linux, systémová volání preadv() a pwritev(), podporu pro zařízení ukládající objekty, cachovací vrstvu na lokálním souborovém systému FS-Cache, několik nových možností sledování, souborový systém Nilfs, mnoho dalších změn v souborových systémech a obrovské množství nových ovladačů. Vizte kompletní changelog, kde najdete všechny detaily.
Současné stabilní jádro 2.6 je 2.6.29.1 vydané 2. února. Obsahuje mnoho oprav chyb v celém stromě, ale specificky by mělo opravit problémy se síťováním, které lidé měli v 2.6.29. Jako vždycky se doporučuje aktualizovat.
-- Ted Ts'o
-- Alan Cox
Od minulého týdne bylo do hlavní řady přidáno nějakých 3400 neslučovacích sad změn, celkem tedy bylo do 2.6.30 začleněno 9600 sad změn. V tomto okamžiku je začleňovací okno 2.6.30 uzavřené. Změny viditelné pro uživatele začleněné za minulý týden zahrnují:
Byla přidána systémová volání preadv() a pwritev(). Jejich cesta byla dlouhá, na LWN se o těchto voláních psalo již v roce 2005. Očekávané rozhraní do uživatelského prostoru je:
ssize_t preadv(int d, const struct iovec *iov, int iovcnt, off_t offset); ssize_t pwritev(int d, const struct iovec *iov, int iovcnt, off_t offset);
Kvůli potížím s portovatelností je nicméně skutečné jaderné rozhraní (které vidí pouze C knihovna) trochu odlišné.
Blokový ovladač smyčky (loop) podporuje nové ioctl() (LOOP_SET_CAPACITY), které lze využít ke změně velikosti zařízení za chodu.
Systémové volání eventfd() přijímá nový příznak (EFD_SEMAPHORE), který způsobí, že volání implementuje jednoduché chování čítacího semaforu (counting-semaphore). Jak to funguje, vizte v záznamu v changelogu.
Souborový systém ext4 je nyní opatrnější co se týče vypisování dat na disk v situacích, kdy jsou zkracovány nebo přejmenovávány malé soubory. Toto chování zvyšuje robustnost v případě pádu, ale také může snižovat výkonnost. Zavedena byla také nová připojovací volba (auto_da_alloc), kterou lze toto chování zakázat. Ext4 má také nové ladící prvky, které lze nalézt v /sys/fs/ext4.
Souborový systém je také opatrnější při zapisování [flush] dat, když běží v režimu data=writeback.
Výchozí režim pro ext3 se změnil z data=ordered na data=writeback. Ten druhý se v 2.6.30 chová o dost lépe, ale také přináší riziko vyzrazení informací, když systém spadne. Distributoři mohou změnit výchozí režim v konfiguraci jádra; někteří si možná zvolí zachovat starší výchozí nastavení data=ordered.
Souborový systém btrfs se také změnil a opatrněji zapisuje data na disk po zkrácení nebo přejmenování.
Byl začleněn strukturovaný logující souborový systém Nilfs
Vrstva MD RAID nyní obsahuje podporu pro ověřování integrity v blokové vrstvě. MD také může změnit chunk_size a rozvržení při operacích reshape - tato schopnost umožňuje změnit RAID5 na RAID6 za běhu.
Souborový systém exofs (dříve osdfs) poskytující podporu pro zařízení ukládající objekty byl začleněn.
FS-Cache (dříve cachefs) byl začleněn. Tento subsystém (na LWN poprvé popsán roku 2004) poskytuje vrstvu pro lokální cachování síťových souborových systémů; konečně překonal obavy některých vývojářů a dostal se do hlavní řady.
Subsystém distribuovaného úložiště a síťový souborový systém pohmelfs byly začleněny. Co je zajímavé, tento kód přišel přes strom -staging.
ATA subsystém získal podporu pro příkaz TRIM.
V /proc/sys/vm jsou dva nové ladící prvky (nr_pdflush_threads_min a nr_pdflush_threads_max); stanovují limity na počet běžících vláken pdflush v systému.
Nyní jsou podporovány jmenné prostory fronty násobných zpráv [multiple message queue].
Architektura PA-RISC získala podporu pro ftrace a latencytop.
Architektura ARM má nyní podporu horní paměti, týká se vás, kdo máte ARM systémy s více než 2 GB RAM.
Architektura Xtensa nyní podporuje systémy bez jednotky správy paměti.
Bloková vrstva: Hostitelské ovladače Marvell MMC/SD/SDIO.
Grafika: framebuffery Samsung S3C.
Síťování: 10GbE PCIe serverové adaptéry Neterion X3100 Series.
Zvuk: audio zařízení HTC Magician
Změny viditelné jaderným vývojářům zahrnují:
Je zde nový nástroj pro ladění paměti řízený konfigurační proměnnou PAGE_POISONING. Zapnutí této vlastnosti způsobí, že bude do každé uvolněné stránky zapsán vzor a při alokaci ověřován. Výsledkem je "velké zpomalení", ale také potenciál pro zachycení mnoha chyb použití po uvolnění [use-after-free].
Nová funkce:
int pci_enable_msi_block(struct pci_dev *dev, int count);
umožňuje ovladači povolit blok MSI přerušení.
Jako součást práce na FS-Cache byl začleněn mechanismus fondu vláken pro "pomalou práci". Někteří vyjádřili naději, že se z něj stane Jediný pravý fond jaderných vláken, ale v tomto směru se zdá být jenom malý pokrok. Více informací vizte v Documentation/slow-work.txt.
Nový pár vypisovacích funkcí:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
int vbin_printf(u32 *bin_buf, size_t size, const char *fmt, ...);
int bstr_printf(char *buf, size_t size, const char *fmt,
const u32 *bin_buf);
Rozdíl zde spočívá v tom, že vbin_printf() uloží binární hodnotu svých argumentů do bin_buf. Proces lze obrátit pomocí bstr_printf(), která formátuje řetězec podle zadaného binárního bufferu. Hlavní využití těchto funkcí je pravděpodobně u Ftrace; umožňují odložit dekódování hodnot, dokud není daný řetězec čten uživatelským prostorem.
Také byla přidána printk_once(), která svou zprávu vypíše pouze při svém prvním zavolání.
Sledovací nástroj "kmemtrace" byl začleněn. Kmemtrace poskytuje data o tom, jak fungují vnitřní slab alokace. Detaily vizte v Documentation/vm/kmemtrace.txt.
Bylo začleněno mnoho změn v ftrace. Je mezi nimi sledovač pracovních front, který sleduje práci vláken pracovní fronty. Sledovač blokového subsystému blktrace lze nyní použít pomocí ftrace. Nový sledovač "event" umožňuje uživateli zapnout specifické sledovací body v jádře; sledovací body byly přidány pro různé události plánovače a přerušení. Nyní jsou k dispozici "čisté" [raw] události (s binárně formátovanými daty). Nový sledovač "syscall" sleduje systémová volání.
Začleňovací okno je nyní uzavřené a může začít proces stabilizace. Zkušenosti z minula naznačují, že do hlavní řady si před vydáním 2.6.30 najde cestu nějakých 3000 dalších změn; to lze očekávat někdy v červnu.
Výročnímu Linux Kernel Summit se možná dostává nejvíce pozornosti, ale kvůli velikosti jaderné komunity je obtížné se na tomto setkání do hloubky věnovat tématům specifickým pro subsystémy. V čím dál větší míře se tedy jaderní vývojáři shromažďují na mnohem cílenějších akcích, kde lze udělat nějakou skutečnou práci. Jednou z těchto událostí je Linux Storage and Filesystem workshop (dílna pro úložná zařízení a souborové systémy v Linuxu); letošní začal 6. dubna. Zde je shrnutí diskuzí, které se konaly první den, od Jonathana Corbeta.
Začalo se rychlou rekapitulací toho, co se projednávalo minulý rok. Některé z těchto věcí byly během doby vyřešeny; mezi ně patří správa napájení, podpora pro zařízení ukládající objekty, fibre channel over Ethernet, zapnuté bariéry ve výchozím nastavení ext4, systémové volání fallocate() a povolení relatime ve výchozím nastavení. Výsledky u dalších cílů již tak dobré nejsou; nízkoúrovňové ošetření chyb stále není tím, čím by mohlo být, "příliš mnoho práce" se udělalo na řadičích I/O pásma, ale nic z ní se nedostalo do upstreamu, problém sjednocujícího souborového systému nebyl vyřešen atd. V celkovém pohledu bylo hodně uděláno, ale hodně zbývá.
Joel Becker a Kay Sievers vedli diskuzi o vyhledávání zařízení [device discovery]. Na současném systému nejsou čísla zařízení stálá mezi jednotlivými booty, ani tak nejsou stálá jména zařízení. Cokoliv v systému, co musí pracovat s blokovými zařízeními a souborovými systémy, musí nejprve najít relevantní zařízení. V současnosti se to provádí prohledáním všech zařízení v systému. To funguje rozumně na laptopu, ale je to skutečný problém na systémech s velkým počtem blokových zařízení. Existují historky o velkých systémech, kterým trvá bootování několik hodin, kde se ve většině tohoto času prohledávají (opakovaně - jednou za každý požadavek na připojení [mount]) všechna známá zařízení.
Z této diskuze samozřejmě vyplývá, že uživatelský prostor potřebuje lepší způsob, jakým vyhledat zařízení. Daný program může hledat specifický popisek [label] souborového systému, UUID či něco jiného; dobré API pro vyhledávání by mělo podporovat všechny tyto režimy i další. Nejlepší by bylo vytvořit nějakou databázi, kam by bylo každé zařízení vloženo již v době jejich vyhledávání. Jak by se objevovaly nové informace (například při nalezení popisku souborového systému), přidávaly by se do databáze. Takže až by se hledal specifický vzor, informace by byly již shromážděny a prohledávání zařízení v systému by již nebylo nutné.
V nejjednodušší formě by touto databází mohly být různé adresáře plné symbolických odkazů, které udev vytváří již nyní. Tyto adresáře řeší velkou část problému, ale kompletním řešením z jednoho důvodu nemohou být nikdy: Některé typy zařízení - iSCSI cíle [target] například - v systému neexistují, dokud se k nim uživatelský prostor nepřipojí. Zařízení s násobnými přístupy [multipath devices] do tohoto soukolí také vhazují dřeváky. Z tohoto důvodu Ted Ts'o prohlásil, že bude vždy potřeba nějaký druh programového API.
Co se specifikace řešení týče, nedošlo k velkému pokroku; hlavní záležitostí se zdálo být dospět ke společnému porozumění problému. K čemu pravděpodobně dojde, je to, že bude knihovna libblkid rozšířena, aby poskytla potřebné funkce. Za rok uvidíme, jestli se tak stalo.
Zach Brown prohlásil, že jeho tématem je "prostě 45 minut nadávat" na špatný stav podpory asynchronního I/O (AIO) v Linuxu. Po deseti letech, říká, máme stále neadekvátní systém, který nikdy nebyl opraven. Problémy s AIO jsou dobře zdokumentovány: Jenom pár operací je opravdu asynchronních, interní API je otřesné, není správně podporováno POSIX AIO API atd. Tam venku, říká Zach, jsou lidé, kteří chtějí s AIO dělat mnohem víc, než je v Linuxu v současnosti podporováno.
Jinak řečeno, postupem času byly navrženy alternativy, ale nikdo je netestuje.
Konverzace se poté trochu posunula; Jeff Moyer si vzal slovo a stěžoval si na příbuzné téma - přímé I/O. V aplikacích funguje špatně, řekl, sémantika je různá pro různé souborové systémy, interní I/O cesty pro přímé I/O jsou úplně odlišné od těch, které se používají pro bufferované I/O, a je plné souběhů a okrajových případů. Nepříliš pěkný obrázek.
Jednou z největších komplikací přímého I/O je potřeba, aby systém podporoval simultánní přímé i bufferované I/O na stejném souboru. Zakázat tuto kombinaci by problém významně zjednodušilo, ale to je těžké udělat. Konkrétně by to mělo tendence rozbít zálohy, které často chtějí číst (v bufferovaném režimu) soubor, který je otevřen pro přímé I/O. Vedl se hovor o přidání nového režimu O_REALLYDIRECT, který by zamkl bufferované operace, ale není jasné, jestli by výhody za tuto cenu stály.
Další věc, která by s přímým I/O pomohla, je odstranit omezení zarovnání [alignment] u I/O bufferů. Tato změna by ale byla obtížná; mnoho řadičů disků umí provádět DMA pouze se správně zarovnanými buffery. Povolení nezarovnaných bufferů by tedy donutilo jádro je kopírovat interně, což poněkud porušuje účel přímého I/O. Je zde nicméně jeden případ, kdy by přímé I/O mohlo takto stále dávat smysl: Někteří uživatelé přímého I/O se ve skutečnosti jenom chtějí vyhnout zaplnění cache stránek systému svými daty. Použití systémového volání fadvise() je pravděpodobně lepším způsobem, jak toho dosáhnout, ale o vývojářích aplikací se říká, že mu nevěří.
Ve shrnutí se z diskuze zdá, že co se týče zlepšení přímého I/O na Linuxu, není toho moc co udělat.
Když se vrátíme k problému s AIO, vývojáři diskutovali Zachem navržené API acall(), které přesouvá blokující operace do k tomu určených jaderných vláken. Použití vláken tímto způsobem slibuje lepší implementaci AIO, než jakou Linux kdy měl. Je zde ale cena: Budou potřeba nějaké změny uvnitř plánovače, aby acall() podporoval. Kromě jiných věcí jsou zde určité složitosti spojené s přenášením osobních údajů [credentials] mezi vlákny, přenosem signálů z AIO vláken zpátky volajícímu procesu atd. Konečným výsledkem je, že výkonnost plánovače může lehce utrpět. Vývojáři plánovače přitom bývají citliví i na malé výkonnostní postihy, takže se může objevit nějaký tlak proti začlenění acall() do hlavní řady.
Přidání acall() by také znamenalo zátěž ohledně údržby. Kdykoliv jaderný vývojář změní strukturu task, bude muset přemýšlet nad tím, jestli je tato změna pro acall() relevantní a jestli ji bude potřeba přesunout do nebo z pracovních vláken.
Závěr je takový, že acall() vypadá slibně a vývojáři v místnosti si mysleli, že by mohlo fungovat. Také se shodli, že mnoho relevantních lidí v místnosti není, takže není možné zodpovědět, jestli je acall() vhodné do jádra jako celku.
Jádro v současnosti obsahuje dvě implementace softwarového RAIDu, v subsystémech MD a device mapperu (DM). K tomu souborový systém Btrfs získává schopnosti RAID sám o sobě, což je proces, který bude pravděpodobně v budoucnu pokračovat. Panuje obecná shoda, že mít tři (či více) implementací RAIDu v jádře není optimální situace. Jak by ale mělo vypadat správné řešení, to není jasné.
Diskuze o sjednocení RAIDu začala touto otázkou: Kdo si myslí, že by se vývoj blokového subsystému měl dít ve vrstvě device mapperu? Zvedla se jediná ruka. Obecně se zdá, že přítomní vývojáři měli relativně nízké mínění o RAID kódu v device mapperu. Samozřejmě by se mělo podotknout, že nebyli přítomni žádní vývojáři DM.
Předmětem diskuze je zde to, že nová generace souborových systémů chce obsahovat podporu pro více zařízení. Plány pro Btrfs obsahují eventuální podporu RAID 6, ale vývojář Btrfs Chris Mason nemá zájem tento kód napsat. Bylo by mnohem hezčí použít obecnou RAID vrstvu poskytovanou jádrem, což má ale své problémy. Souborový systém schopný RAIDu například chce použít různé velikosti proužků [stripe] pro data a metadata. Standardní RAID, který o souborovém systému na něm postaveném ví jenom málo, takovou možnost ale neposkytuje.
Jak by tedy vypadalo RAID API pro souborové systémy? Christoph Hellwig na problému pracuje, ale ještě není připraven řešit souborové systémy. Místo toho začne tím, že se pokusí přijít na to, jak sjednotit RAID kód MD a DM. Část této práce může zahrnovat vytvoření sady tabulek v blokové vrstvě, podle kterých se budou specifické oblasti virtuálního zařízení mapovat na skutečné oblasti zařízení na nižší úrovni. Bloková vrstva to již dělá - takto fungují oddíly - ale začlenění RAIDu by věci významně zkomplikovalo. Nicméně, až bude toto hotovo, budeme mnohem blíže k tomu mít obecnou RAID vrstvu, kterou by mohlo použít více volajících.
Hovor se poté na chvíli přesunul k ošetřování chyb. Konkrétně k tomu, že nástroje, které Linux poskytuje administrátorům k řešení špatných bloků, stále nejsou tím, čím by mohly být. Hovořilo se o poskytnutí konzistentního rozhraní pro hlášení chybných sektorů - včetně nástrojů pro mapování těchto bloků na soubory, které je obsahují - stejně jako pro provádění pasivního vyhledávání vadných bloků.
Úkoly, které z této diskuze vyplynuly, zahrnují přepracování jaderného RAIDu Christophem. Poté začne proces pokusů definovat rozhraní specifická pro souborové systémy.
Před přednáškou Teda Ts'o o fsync() a rename() nějaký vtipálek nechal v místnosti stránky s omalovánkami, na kterých byl zobrazen poník. Tyto stránky odrážejí Tedův povzdech, který často opakuje: Vývojáři aplikací chtějí od souborového systému příliš mnoho, takže by mohli klidně požadovat poníka, když už jsou v tom.
Ted se obecenstvu omluvil za svou úlohu v implementaci režimu data=ordered v ext3. Tento režim byl přidán jako způsob, jak vylepšit bezpečnost souborového systému, ale měl vedlejší efekt zapisování všech změn souborového systému na disk během pětivteřinového okna. To umožnilo autorům aplikací "zlenivět" a přestat se obávat o to, jestli se jejich data opravdu dostala na disk ve správný čas. Nyní tito vývojáři oponují návrhu, že by se opět měli obávat.
Tento problém má delší historii, než si mnoho lidí uvědomuje. Souborový systém XFS na něj narazil okolo roku 2001. Ted říká, že většina vývojářů aplikací nepochopila, proč jsou jejich soubory po pádu poškozené. Místo toho, aby své aplikace opravili, prostě změnili souborový systém - na ext3. Věci po nějaký čas fungovaly, dokud uživatelé Ubuntu nezačali testovat alpha verzi "Jaunty", která používá jako výchozí ext4 umožňuje volitelně instalovat na ext4. V tu chvíli začali po pádu nacházet soubory o nulové délce a obvinili ext4.
Podle Teda jsou ale skutečným problémem chybějící volání fsync(). Je několik důvodů, proč chybí, mezi ně patří lenost vývojářů, problém, že na ext3 je fsync() velmi drahý, obtíže se zachováváním seznamů řízení přístupu [access control list] a dalších rozšířených atributů při vytváření nových souborů a obavy o dopadu na výdrž na baterie, když je disk donucen k roztáčení. Ted má pro některé z těchto důvodů více sympatií než pro jiné, ale říká, že "vývojáři aplikací jsou v přesile", takže bude potřeba udělat něco, aby byly jejich obavy vyslyšeny.
Valerie Aurora mu skočila do řeči a podotkla, že vývojáři aplikací jsou postaveni do pozice, ve které nemůžou udělat správnou věc. Volání fsync() může na ext3 systém na poměrně dlouhou dobu zastavit. To se uživatelům také nelíbí; důkazem je povyk způsobený nadměrným používáním fsync() prohlížečem Firefox. Není to tedy jenom o tom, že vývojáři aplikací jsou líní; používání fsync() má skutečné překážky. Ted souhlasil, ale také tvrdil, že mnoho vývojářů aplikací odmítá pomoci problém opravit.
Jako krátkodobé řešení ext4 získal několik opatření, která brání těm nejhorším překvapením. Pokud je nově zapisovaný soubor přejmenován na místo jiného, existujícího souboru, jeho data budou vypsána na disk při příštím commitu. Podobné věci se dějí u souborů, které byly zkráceny nebo přepsány. Tyto změny mají dopad na výkonnost, ale velká část problémů díky nim zmizí.
Co se dlouhodobého měřítka týče, Ted se zeptal: Měly by se opravy popsané výše stát částí politiky souborových systému v Linuxu? Jinými slovy, měli by vývojáři aplikací dostat jistotu, že mohou zapsat do souboru, přejmenovat ho na místo jiného, vynechat fsync() a nenarazit po pádu na soubor o nulové délce? Ukázalo se, že odpověď je "ano", ale předtím Ted prezentoval své další dlouhodobé nápady.
Jedním z nichž je vylepšit výkonnost systémového volání fsync(). Opatření pro ext4 byla přidána i do ext3, když běží v režimu data=writeback. Krom toho byly do blokové vrstvy v 2.6.30 přidány nějaké opravy. S těmito opravami je možné pracovat v režimu data=writeback, vyhnout se problému souborů o nulové délce a také problému výkonnosti fsync(). Měl by tedy režim data=writeback být nastaven jako výchozí pro ext3?
Tento nápad byl přijat se značnou nelibostí. Režim data=writeback přináší problémy, které byly opraveny v data=ordered; po pádu bylo možné, že se v souboru, do kterého se zapisovalo, objevila úplně cizí data. Mohla to být něčí citlivá data a i kdyby to byla jenom nudná data, pro příliš mnoho uživatelů tento problém vypadá jako poškození dat. Vypadá to jako krok zpátky a jako změna, kterou je u souborového systému mířícího směrem k udržovacímu režimu těžké ospravedlnit. Bylo by tedy překvapující, kdyby tato změna prošla.
[Po dopsání předchozího odstavce si autor všiml, že Linus právě začlenil změnu, díky které je data=writeback v 2.6.30 pro ext3 výchozí. Autora lze zjevně snadno překvapit.]
Nakonec byl přednesen nápad systémového volání fbarrier(). Pomocí fbarrier() by v podstatě zajistilo, že data zapsaná do souboru před tímto voláním by byla vypsána na disk předtím, než by došlo ke změně metadat požadovaných po tomto volání. Bylo by možné implementovat to pomocí fsync(); pro režim ext3 data=ordered by funkce nedělala nic. Ted se příliš nesnažil toto systémové volání prosazovat, řekl, že slouží hlavně k tomu, aby se reagovalo na obavy ze spotřeby energie laptopů. Ric Wheeler tvrdil, že by to byla ztráta času; než by lidé toto volání opravdu začali používat, budeme v laptopech mít SSD disky a potíže s napájením zmizí. Obecně bylo nadšení pro fbarrier() malé.
Diskuze se tak vrátila zpět k nápadu zobecnění a garantování opatření u ext4. Chris Mason se zeptal, jestli neexistuje případ, kdy by někdo nechtěl přejmenovávat soubory bezpečně; odpověď nedostal. Byla zde obava z toho, že těmto opatřením by se nemělo dovolit narušit výkonnost dobře napsaných aplikací, obecným náhledem ale bylo to, že tato opatření by se měla stát politikou, kterou by měly implementovat všechny souborové systémy.
Konala se diskuze o podpoře paralelního NFS (pNFS). Šlo z většiny o detailní technickou diskuzi o tom, jaký druh API bude potřeba, aby se clusterovým souborovým systémům umožnilo říci pNFS o tom, jak jsou soubory distribuovány mezi servery. Autor článku zde přiznává, že chvíli nedával pozor a že jeho poznámky jsou relativně nesouvislé. Postačí říct, že OCFS2 a GFS budou nakonec moci komunikovat s pNFS servery a že lidé, které bude opravdu zajímat, jak to funguje, tomu porozumí.
Poslední diskuze tohoto dne se týkala "různých témat VFS"; první byla o eCryptfs. Tento souborový systém umožňuje šifrování jednotlivých souborů; je v současnosti implementován jako skládaný souborový systém používající běžný souborový systém, který poskytuje skutečné ukládání. Skládající povaha eCryptfs dlouho představovala problém; nyní někteří vývojáři Ubuntu pracují na změně.
To, co by konkrétně rádi udělali, je přesun obsluhy šifrování přímo do vrstvy VFS. Uživatelé nějak dodají jádru klíč a jádro poté bude transparentně řešit šifrování a dešifrování dat. Za tímto účelem bude k dispozici nějaká transformační vrstva, která bude zpracovávat data mezi cache stránek a blokovým zařízením pod ní.
Jedna otázka, která se objevila, byla: Co se stane, když uživatel nebude mít platný klíč? Měla by VFS prostě v takovém případě poskytnout zašifrovaná data? Al Viro položil otázku, co se stane, pokud jeden proces otevře soubor s klíčem a druhý bez něj. V takové situaci bude v cache směs zašifrovaných a čitelných stránek, což je situace, která téměř jistě povede ke zmatku. Zdá se tedy, že VFS jednoduše odmítne poskytnout přístup k souborům, pokud nebude klíč poskytnut.
Co se týče vytvoření transformační vrstvy, je několik problémů, které je potřeba vyřešit - věci jako nenechat procesy měnit stránku, když je šifrována nebo dešifrována. Chris Mason poznamenal, že podobnému problému čelí, když generuje kontrolní součty stránek v Btrfs. To jsou ale problémy, které lze řešit. Bylo jasné, že tento druh transformace bude pravděpodobně do VFS v budoucnu zabudován, vrstvené souborové systémy prostě v linuxové VFS, tak jak nyní existuje, nefungují dobře.
Další na řadě byl David Brown, který pracuje na poli vysoce výkonných vědeckých výpočtů. David má zajímavý problém. Provozuje obrovské systémy s velkými úložnými poli rozloženými mezi mnoho strojů. Kdykoliv nějaký proces zavolá stat() na soubor uložený na tomto poli, celý cluster se v podstatě musí zastavit. Je potřeba získat zámky, stránky v cache je potřeba zapsat atd., jenom aby se zajistilo, že specifická metadata (konkrétně velikost souboru) jsou k dispozici a správná. Takže když se vědec přihlásí a napíše "ls" ve velkém adresáři, na výsledek se může čekat 30 minut a v té době se udělá jenom málo práce. Neideální.
Co by David rád, by bylo volání "stat() light", které by nezpůsobilo tolik potíží. Mělo by vrátit metadata podle svých nejlepších vědomostí, ale nezapisovat přitom cache nebo zamykat celoclusterové zámky, aby tuto informaci získalo. Pokud to bude znamenat, že velikost nebude úplně přesná, tak ať. V následné diskuzi byl tento nápad trochu modifikován. "Lehce nepřesné" výsledky by nebyly vraceny; místo toho by velikost byla jednoduše vynulována. Účastníci diskuze měli pocit, že nevrátit vůbec žádnou informaci je lepší, než vrátit něco, co nemá žádný reálný základ.
Krom toho by s tímto systémovým voláním pravděpodobně existovala maska. V počátku bylo navrženo, že tato maska by byla vrácena; v ní by byly nastavené bity, které by indikovaly, která pole ve vrácené struktuře stat jsou platná. Také ale bylo navrženo, že maska by místo toho měla být vstupním parametrem; volání by potom udělalo všechno, co je potřeba, aby poskytlo pole vyžadovaná uživatelem. Použitím masky jako vstupního parametru by se odstranila duplicitní volání v případě, že potřebné informace nejsou napoprvé k dispozici.
Skutečná podoba systémového volání bude pravděpodobně určena, až se někdo zařídí podle rady Christopha Hellwiga "pošlete zatracený patch".
Posledním tématem dne byla sjednocující připojení. Valerie Aurora, která diskuzi vedla, nedávno pro LWN napsala článek o sjednocujících souborových systémech a s nimi spojených problémech. Diskuze se zaměřila hlavně na systémové volání readdir(). POSIX vyžaduje, aby readdir() vracelo pozici v adresáři, kterou může aplikace kdykoliv v budoucnu použít, aby se vrátila na stejné místo a pokračovala ve čtení záznamů v adresáři. Tento požadavek je obtížné splnit pro každý současný souborový systém; je to téměř nemožné pro sjednocující souborové systémy, které - z definice - předkládají kombinaci přinejmenším dvou jiných souborových systémů.
Řešení, které Valerie navrhla, bylo jednoduše vytvořit adresáře na nejvyšší (zapisovatelné) vrstvě sjednocení. Nové adresáře by ukazovaly na soubory na správných místech ve sjednocení a byla by na nich aplikována vybělení. To by odstranilo potřebu míchat později záznamy v adresáři z několika vrstev a problém s readdir() by se smrskl zpět na implementaci v jediném souborovém systému. To je pravda, přinejmenším pokud se žádný ze souborových systémů na nižší vrstvě nezmění. Valerie navrhuje, aby se pro tyto souborové systémy vynutil režim pouze pro čtení; aby je bylo možné měnit, byl by potřeba umount.
Dobrá zpráva je, že tímto způsobem sjednocující připojení v BSD fungují již dlouho.
Špatná zpráva je, že je zde jeden s tím spojený problém: stabilita čísel inodů. Od NFS serverů se očekává, že poskytnou stabilní čísla inodů klientům i mezi rebooty. Kopírování záznamu o souboru na nejvyšší vrstvu sjednocení ale jeho číslo inodu změní, což NFS klienty zmate. Jedním možným řešením je prostě deklarovat, že sjednocená připojení není možné exportovat přes NFS; není jasné, jestli takový export má vůbec nějaké rozumné použití. Další řešení je prostě nechat čísla inodů měnit se. To by mohlo vést k tomu, že by různé NFS klienty mohly mít otevřené popisovače různých verzí souborů, ale budiž. Zdá se, že konsenzus se přikláněl k druhému řešení.
Tím první den skončil. Autor článku se bude účastnit větší části druhého a závěrečného dne (mínus krátká absence kvůli miniaturnímu výskytu na Embedded Linux Conference)..
Druhý den Linux Storage and Filesystem Workshop se konal v San Franciscu v Kalifornii 7. dubna. Souběžné závazky zabránily Jonathanu Corbetovi být přítomen u celé události, ale byl schopen se účastnit diskuzí o podpoře disků bez rotujících částí (solid-state device), informací o topologii úložných zařízení a dalších.
Téma disků bez rotujících částí bylo nejaktivnější diskuzí rána. SSD se zjevně cítí na to změnit krajinu úložných zařízení, ale často se zdá, že nikdo ještě nezjistil, jak se věci změní nebo co by jádro mělo udělat, aby tato zařízení využívalo co nejlépe. Některé z těchto otázek se nicméně vyjasňují - jádro bude v dobré pozici podporovat současnou generaci SSD. Podpora budoucích produktů nicméně bude výzvou.
Matthew Wilcox, který vedl diskuzi, začal upozorněním na to, že SSD od Intelu jsou schopné zvládat několik operací paralelně. Paralelismus je ve skutečnosti tak dobrý, že má jenom malou nebo dokonce žádnou výhodu operace zpožďovat. I/O požadavky by měly být vysílány okamžitě, blokový I/O subsystém by se dokonce neměl ani pokoušet blízké požadavky slučovat. Toto tvrzení bylo o něco později zmírněno, ale jádro zůstává: když jádro řídí SSD, mělo by se mělo soustředit na to nestát v cestě a zpracovat operace tak rychle, jak je to jenom možné.
Padla otázka: Jak tyto disky fungují interně? Bylo by hezké to vědět; čím lepší informace jaderní vývojáři mají, tím lépe mohou vyřešit používání těchto zařízení. Zdá se nicméně, že firmware v těchto zařízeních - ta část, díky které prozatím zařízení od Intelu fungují lépe než většina alternativ - je plný Cenného Duševního Vlastnictví a příliš mnoho informací nebude. SSD zařízení budou v blízké budoucnosti černé skříňky.
V každém případě nejsou SSD od Intelu jediným typem zařízení, se kterým bude muset jádro pracovat. Disky se v následujících letech budou značně lišit. Co jádro skutečně potřebuje vědět, je několik základních parametrů: jaký druh zarovnání požadavků funguje nejlépe, jaké velikosti požadavků jsou nejrychlejší, atd. Bylo by hezké, kdyby byly disky schopny exportovat tyto informace operačnímu systému. Existuje mechanismus, kterým to lze udělat, ale současné disky příliš mnoho informací nezveřejňují.
Jedno jasné pravidlo nicméně zůstává: Větší požadavky jsou lepší. Mohou se lépe chovat na disku jako takovém, ale u vysoce kvalitních SSD je jediným úzkým hrdlem prostý počet požadavků, které lze vygenerovat a zpracovat za jednotku času. Zabalit věci do většího požadavku by mělo zvýšit celkovou propustnost.
S tím spojené pravidlo souvisí se vzory využívání. Zdá se, že disky od Intelu, přinejmenším, pozorují požadavky vysílané počítačem a adaptují se tak, aby zlepšily výkon. Konkrétně se mohou dívat na typické zarovnání požadavků. Výsledkem je, že je důležité dát disku vědět, že vzor využívání se změní - když jsou na disku změněny oddíly a použije se jiný souborový systém například. Způsob, jakým to udělat, je evidentně vyslat ATA příkaz "bezpečný výmaz" [secure erase].
Odtud se konverzace přesunula k požadavkům zahození (nebo "zkrácení" [trim]), které hostitel používá k tomu, aby disku oznámil, že obsah specifických bloků již není zapotřebí. Rozvážné používání požadavků zkrácení může disku pomoci při sběru odpadu [garbage collection], čímž se zlepší jak výkonnost, tak celková životnost hardwaru. Co ale znamená "rozvážné používání"? Zkrácení, když je vytvořen nový souborový systém, je jeden zjevný kandidát. Když jádro inicializuje swap soubor, zkrátí ho celý, neboť v něm nemůže být nic užitečného. Zde nic kontroverzního není (i když je možné s úsměvem podotknout, že mkfs ještě příkaz zkrácení nevysílá).
Co ale když se změní tabulka oddílů? Bylo navrženo, že ta část disku, která se přesouvá z jednoho oddílu do jiného, může být zkrácena. To ale nastoluje okamžitý problém: Jestliže byla tabulka oddílů poškozena a její "změna" je ve skutečnosti pokusem o obnovu disku do funkčního stavu, zkráceni dat by byla fatální chyba. Totéž platí pro používání zkrácení v příkazu fsck, což je další nápad, který byl navržen. Nakonec není jasné, jestli je používání zkrácení v obou případech bezpečné.
Další zjevné místo, kde lze použít příkaz zkrácení, je při výmazu souboru; koneckonců, mazaná data již jistě nejsou zapotřebí. Někteří lidé ale zpochybnili i toto - obnovování dat je jeden problém; lidé někdy chtějí obnovit obsah chybně smazaného souboru. Je zde ale také potenciální problém s výkonností: na ATA discích nelze příkazy zkrácení vyslat jako označené příkazy [tagged commands]. Když je tedy provedeno zkrácení, všechny běžné operace se musí zastavit. Pokud se to bude dít často, utrpí propustnost disku. Tento problém lze zmírnit ukládáním zkracovacích operací a jejich vysláním naráz každých několik minut. Není ale zjevné, jestli je skutečný dopad na výkonnost natolik velký, aby to tuto snahu ospravedlnilo. Bude potřeba pokusit se problém nějak kvantifikovat benchmarkováním.
Alternativa, která byla navržena, byla zkracování vůbec nepoužívat. Místo toho by bylo možné dosáhnout podobného výsledku jednoduchým využíváním stejného logického bloku znova a znova. Primitivní implementace by vždycky prostě aplikaci alokovala nejníže číslovaný volný blok, když by bylo potřeba volné místo, čímž by se data komprimovala u konce disku. Tento přístup má nicméně pár problémů počínaje faktem, že mnoho z levnějších SSD má mizernou implementaci vyrovnávání opotřebení. Znovuvyužívání bloků s nízkými čísly by tyto disky opotřebovalo předčasně. Další problém je, že alokování bloků tímto způsobem by mělo tendenci fragmentovat soubory. Cena za fragmentaci je mnohem menší než u rotujících disků, ale stále má cenu udržovat soubory spojité. Konkrétně to umožňuje rozsáhlejší I/O operace a tím větší výkonnost.
Došlo i k vedlejší diskuzi o tom, jak by jádro mohlo být schopné rozlišit "mizerné" disky od těch, které mají zabudované skutečné vyrovnání opotřebení. Skutečně se mluví o tom vytvořit nějaké parametry s neutrální hodnotou, které by disk mohl použít k tomu, aby tuto informaci exportovat. Ale zdá se, že nikdo si nedělá naděje, že by to výrobci používali správně. Žádný výrobce hardwaru nebude chtít identifikovat svůj produkt jako méně kvalitní. Padl návrh, že by jádro mohlo interpretovat podporu příkazu ke zkrácení jako indikátor, že pracuje s jedním z lepších disků. To vedlo k odhalení, že tolik opěvované disky od Intelu zkrácení v současnosti nepodporují. To se ale v budoucích verzích změní.
S tím spojené téma bylo umožnit aplikacím vysílat operace na zkrácení částí souborů. Správce databáze by tuto funkci mohl použít k tomu, aby systému sdělil, že ho již nebude zajímat současný obsah sady bloků souboru. Jde v podstatě o verzi dlouho diskutovaného systémového volání punch() s tím rozdílem, že bloky by zůstaly alokované souboru. Dealokování bloků by bylo korektní na jedné úrovni, ale vedlo by to k tendenci soubor postupně fragmentovat, vynucovat transakce žurnálu a operace s O_DIRECT by blokovaly, dokud by se nealokovalo místo. Vývojáři databází by se rádi vyhnuli všem těmto důsledkům. Tato varianta punch() (možná ve skutečnosti varianta fallocate()) by zahodila data, ale bloky by zůstaly na místě.
Odtud se diskuze přesunula ke zdánlivě nesouvisejícímu tématu ztenčené rezervace [thin provisioning]. To je nabídka od některých výrobců velkých úložných polí; prodají pole, které tvrdí, že je mnohem větší, než ve skutečnosti je. Když dostupné místo poklesne, zákazník si od výrobce může koupit více disků. Z pohledu systému se ale velikost pole nemění.
Poskytovatelé ztenčené rezervace mohou používat příkaz ke zkrácení také; dává jim na vědomí, že indikované místo se nepoužívá a lze ho alokovat jinde. To ale vede k zajímavému problému, pokud se zkrácení použije k vyřazení obsahu několika bloků uprostřed souboru. Pokud aplikace do těchto bloků - které jsou teoreticky stále na stejném místě - zapíše, systém může zjistit, že na zařízení došlo místo a požadavek selže. A to obratem může vést k chaosu.
Pravda v této záležitosti je taková, že ztenčená rezervace má tento problém bez ohledu na využívání příkazu ke zkrácení. Místo "alokované" pomocí fallocate() se může ukázat jako stejně iluzorní. Pokud dojde místo, když se systém pokusí zapsat metadata, kód souborového systému pravděpodobně zpanikaří, připojí souborový systém pouze pro čtení a možná systém shodí. Ztenčenou rezervaci tedy lze považovat za rozbitou již teď. Co je potřeba opravit, je způsob, jakým operační systém řekne úložnému zařízení, že má v plánu specifické bloky použít; to je nápad, který bude přednesen relevantním komisím pro standardy.
Nakonec proběhla i diskuze o I/O plánovači CFQ, který obsahuje spoustu inteligence, která pro SSD není zapotřebí. Existuje způsob, jak pro některé SSD operace CFQ obejít, ale i tak přidává přibližně 3% postih výkonnosti v porovnání s I/O plánovačem no-op. Tato cena je nyní snesitelná, ale u budoucích zařízení to takto nepůjde. Jde o to mít možnost provést na SSD 100 000 operací za sekundu - nebo víc. Tento druh tempa I/O neponechává příliš prostoru pro režii systému. V určitém bodě uvidíme skutečnou snahu o to narovnat I/O cesty blokové vrstvy, aby se zajistilo, že Linux bude schopen dál využívat co nejvíce z úložišť bez rotujících částí.
Martin Petersen představil problém topologie úložných zařízení přednáškou o přicházejících sektorech o velikosti 4k. Smutný fakt je, že přes veškeré povídání o SSD s námi rotující disky budou ještě nějakou dobu. A výrobci diskových jednotek mají v úmyslu přejít na sektory o velikosti 4k do roku 2011. To vede k mnoha zajímavým problémům s podporou, z nichž většina byla zmíněna v tomto článku v březnových Jaderných novinách. Jádro bude nakonec muset o velikostech I/O a potřebách zarovnání vědět mnohem více, aby bylo schopno obsluhovat budoucí disky.
Za tímto účelem Martin připravil sadu patchů, které tyto informace exportují systému. Výsledkem je sada adresářů v /sys/block/disk/topology, kde je k dispozici velikost sektoru, potřebné zarovnání, optimální I/O příznak a další. Také je zde "příznak konzistentnosti", který uživateli říká, jestli tyto informace opravdu odpovídají realitě. V některých situacích (například zrcadlený RAID vytvořený z disků, které mají různé vlastnosti) není možné poskytnout skutečné informace, takže si jádro musí něco vymyslet.
Byly nějaké námitky k tomu, že se zde používá sysfs, ale potřebnost těchto informací je jasná. Tyto patche budou tedy pravděpodobně začleněny do jádra 2.6.31.
Také se konala diskuze o navrhovaném systémovém volání readdirplus(). Toto volání by fungovalo v podstatě jako readdir() (nebo pravděpodobněji jako getdents()), ale se jmény by poskytovalo i metadata. To by umožnilo vyhnout se samostatnému volání stat() a snad tedy i ke zrychlení v některých situacích.
Většina diskuze se týkala toho, jak by toto systémové volání bylo implementováno. Je patrná velká snaha se vyhnout vytvoření oddělených implementací readdir() a readdirplus() pro každý souborový systém. Je potřeba najít způsob, jak interní implementace těchto systémových volání sjednotit. To by se nejpravděpodobněji provedlo tak, že by se používala pouze funkce readdirplus(), pokud souborový systém nějakou nabízí; zpětné volání [callback] by mělo příznak "nejsou potřeba stat informace" pro případ, že se volá normální readdir().
Vytvoření tohoto systémového volání vypadá jako příležitost oprostit se od starých chyb. Například by nebylo podporováno hledání [seek] v adresáři. Také by pravděpodobně vznikla nová struktura dirent, která by pro většinu parametrů měla 64bitové pole. Kromě těchto dvou je nicméně podoba nového systémového volání poněkud zamlžená. Někdo by zjevně měl poslat patch.
Zde workshop skončil - přinejmenším ta část, které se autor článku mohl zúčastnit. Proběhlo několik diskuzí spojených s ukládáním, které se bezpochyby zabývaly zajímavými tématy, ale nebylo možné být v obou místnostech naráz (i když s trochou štěstí autor článku obdrží poznámky z těchto diskuzí od jiného z účastníků). Účastníci se shodli na tom, že šlo o velmi úspěšnou a užitečnou událost; výsledky by se během následujícího roku měly prohnat přes jaderný strom.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Mam pocit, ze autor vo vete "...tenhle kousek jsem u farmy zvířat..." myslel Orwellovu Zvieraciu farmu, nie len tak nejaku "farmu zvirat"...
19.5.2009 11:45
Jan Drábek | skóre: 41
| blog: Tartar
| Brno
Farmu zvířat, co s ní? chybí velké písmeno?
Když jdáro inicializujejdáro –> jádro
Zde workshop skončiskončil
SSD se zjevně cítí na to změnit krajinu úložných zařízení, ale často se zdá, že nikdo ještě nezjistil, jak se věci změní nebo co by jádro mělo udělat, aby tato zařízení využívalo co nejlépe.
Ještě by mohli pořešit omezení jednoho procesu kcryptd na odíl.