Unicode Consortium, nezisková organizace koordinující rozvoj standardu Unicode, oznámila vydání Unicode 16.0. Přidáno bylo 5 185 nových znaků. Celkově jich je 154 998. Přibylo 7 nových Emoji.
Byla vydána nová major verze 1.0 oficiálního firmwaru pro zařízení Flipper Zero (Wikipedie). Po třech letech vývoje. Přehled novinek i s náhledy a videi v příspěvku na blogu: podpora aplikací třetích stran, nový NFC podsystém, podpora JavaScriptu pro psaní aplikací, vylepšení spotřeby, zrychlení Bluetooth přenosu…
Radicle, distribuovaná alternativa k softwaru pro spolupráci jako např. GitLab, byl vydán ve verzi 1.0. Nyní obsahuje nad gitem postavený, rozšiřitelný protokol pro diskuze a nakládání s patchi, autentizaci a autorizaci, integraci Toru a uživatelské rozhraní v příkazovém řádku či jednoduché webové rozhraní pro prohlížení repozitářů. Projekt byl dříve představen a diskutován na Linux Weekly News.
Byla vydána nová verze 6.7 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 13.5.3. Thunderbird na verzi 115.15.0. OnionShare z verze 2.2 na verzi 2.6.
Rozsudky Soudního dvora Evropské unie ve věcech C-465/20 P (Apple) a C-48/22 P (Google a Alphabet): Irsko poskytlo společnosti Apple protiprávní daňová zvýhodnění ve výši 13 miliard eur a je povinné je získat zpět. Byla potvrzena pokuta ve výši 2,4 miliardy eur uložená společnosti Google za to, že zneužívala svého dominantního postavení tím, že upřednostňovala vlastní službu srovnávání výrobků.
Apache Cassandra (Wikipedie), tj. open source NoSQL distribuovaná databáze, byla vydána v nové major verzi 5.0. Přehled novinek v příspěvku na blogu a v souboru NEWS na GitHubu.
Společnost MNT Research oznámila, že po open source noteboocích MNT Reform a MNT Pocket Reform bude následovat MNT Reform Next. Časem se objeví na Crowd Supply. Vývoj lze sledovat na Mastodonu.
Apple představil (YouTube) telefony iPhone 16 Pro a iPhone 16, hodinky Watch Series 10 a Watch Ultra 2 a sluchátka AirPods 4, AirPods Pro 2 a AirPods Max.
Byla vydána verze 0.9.0 operačního systému Redox OS (Wikipedie). Jedná se o mikrokernelový unixový operační systém naprogramovaný v programovacím jazyce Rust. Zdrojové kódy jsou k dispozici na GitLabu pod licencí MIT. Z novinek lze vypíchnout aplikace Files, Editor a Terminal z desktopového prostředí COSMIC, RustPython nebo webový server Simple HTTP Server.
Dnes ve 23:59 končí hlasování o přednáškách na konferenci LinuxDays 2024, která proběhne o víkendu 12. a 13. října v Praze.
Originál tohoto článku pro LWN.net napsala Valerie Aurora (dříve Hensonová).
Když řeknete „do záznamů strukturované souborové systémy“ [log-structured file system], většině vývojářů v oboru úložných zařízení se okamžitě vybaví klasické pojednání Ousterhouta a Rosenbluma – Návrh a implementace do záznamů strukturovaného souborového systému – a téměř dvě dekády následné snahy vyřešit ošklivý problém s čištěním segmentů (vizte níže), který se objevil s ním. Vývojáři Linuxu si mohou vybavit JFFS2, NILFS nebo LogFS, tři z několika moderních do záznamů strukturovaných souborových systémů specializovaných pro použití v zařízeních bez rotujících částí (SSD). Méně lidí si vybaví firmware v SSD. Překladová flash vrstva v moderních SSD připomíná do záznamů strukturovaný souborový systém v několika důležitých ohledech. Extrapolace z výzkumů těchto souborových systémů nám umožňuje předpovědět, jak z SSD vytěžit nejvyšší výkon – konkrétně plná podpora příkazu TRIM na úrovni SSD i souborového systému bude klíčem k dlouhodobému udržení vrcholné výkonnosti většiny SSD.
Do záznamů strukturované souborové systémy, se - což je poměrně podivné – vyvinuly z logujících souborových systémů. Logující (nebo žurnálující) souborový systém je normální souborový systém se zápisem na místě ve stylu ext2 nebo FFS s tím, že je k němu připíchnuto logování zápisových operací. (V tomto článku budeme používat termín „žurnálující souborový systém“, aby nedošlo k záměně „logujících“ [zaznamenávajících] a „do záznamů strukturovaných“ souborových systémů.) Žurnálující souborový systém udržuje stav souborového systému na disku konzistentní tím, že do logu zapíše shrnutí každé zápisové operace na nějaké nonvolatilní úložiště, jako je disk (nebo NVRAM, pokud na to máte peníze), předtím než se změny zapíší na své dlouhodobé umístění v souborovém systému. Toto shrnutí nebo záznam v logu obsahuje dostatek informací k tomu, aby bylo možné celou operaci zopakovat, pokud je přímý zápis do souborového systému přerušen v půli (například pádem systému). Toto opakování operace se nazývá přehrávání logu. V krátkosti je tedy každá změna souborového systému na disk zapsána dvakrát: Jednou do logu a jednou na trvalé umístění.
Okolo roku 1988 si John K. Ousterhout a několik jeho spolupracovníků všimli, že druhý zápis by bylo možné úplně vynechat, pokud budou celý souborový systém považovat za obrovský log. Místo zapsání operace do logu a poté přepsání změn na jejich místě někde jinde by stačilo zapsat změnu jednou na konec logu (ať je to kdekoliv) a tím s ní skončit. Zápisy do existujících souborů a inodů jsou kopírovány při zápisu [copy on write] – stará verze je označena jako volné místo a nová verze je zapsána na konec logu. Zjištění současného stavu souborového systému je koncepčně záležitostí přehrání celého logu od začátku do konce. Prakticky do záznamů strukturovaný souborový systém periodicky vytváří snímky; tyto snímky popisují stav souborového systému v daném okamžiku bez potřeby přehrávat log. Všechny změny souborového systému od snímku dále jsou zjištěny přehráním relativně malého počtu záznamů v logu, které snímek následují.
Jednou ze zajímavých výhod struktury do záznamů strukturovaného souborového systému (LFS) je, že je většina zápisů do souborového systému sekvenční. Sekce popisující motivaci pro Sprite LFS, napsaná téměř před dvaceti lety, ukazuje, jak málo se ve světě úložných zařízení změnilo:
Ale moment, proč pořád mluvíme o posunování hlaviček? SSD totálně změnily výkonnostní charakteristiky úložných zařízení! Disky jsou mrtvé! Ať žije flash!
Co je překvapující, do záznamů strukturované souborové systémy jsou, když dojde na SSD, relevantnější než kdy jindy. Základní předpoklad pro souborové systémy založené na záznamech – že čtení je levné a zápisy jsou drahé – je naprosto platný pro základní stavební bloky SSD, na NAND založené flash paměti. (Po zbytek tohoto článku „flash“ znamená na NAND-založenou flash a SSD znamená na této flash založené zařízení s překladovou vrstvou pro vyrovnávání opotřebení a shromažďování zápisů.) Když dojde na flash, číst lze s malou granularitou – obvykle po stovkách bytů, ale zápisy je nutné provádět ve velkých spojitých blocích – řádově v desítkách nebo stovkách tisících bytů. Zápis na flash má dva kroky: V prvním se vymaže celý blok, přičemž se všechny bity nastaví na stejnou hodnotu (obvykle – proti intuici – jedničku). V druhém jsou potom jednotlivé bity v bloku překlopeny zpět na nulu, až nakonec dostaneme blok, který jsme chtěli.
Do záznamů strukturovaný souborový systém je pro flash přirozeným partnerem. Jedním z detailů do záznamů strukturovaného návrhu je, že se záznamy zapisují ve velkých spojitých kusech nazvaných „segmenty“, které mají řádově megabyty. Aby se snížila režie způsobená metadaty a získala co největší výkonnost, záznamy jsou seskupovány a zapsány sekvenčně do úplně volného segmentu. Většina segmentů je přitom v daný okamžik částečně využita a částečně volná, takže souborový systém musí sesbírat všechna používaná data segmentu a přesunout je jinam předtím, než do segmentu bude možné zapisovat. Když souborový systém potřebuje další segment, nejprve vyčistí existující částečně využitý segment tím, že přesune všechna používaná nebo živá data do jiného volného segmentu – zjednodušeně sbírá odpad [collects garbage]. Teprve poté je všechno připraveno a souborový systém může v jednom velkém proudu zapsat do prázdného segmentu. Tento systém segmentů a jejich pročišťování je přesně to, co je potřeba pro efektivní zápis do flashového zařízení, vzhledem ke nutnosti vymazat velké spojité bloky flash před zápisem do nich.
Shoda mezi do záznamů strukturovanými souborovými systémy a flash je zjevná, když se podíváme na souborové systémy napsané pro rozhraní, které umožňuje pracovat přímo s flash – tj. pro zařízení bez zabudovaného vyrovnávání opotřebení a sběru zápisů. Souborové systémy, které ví o výmazových blocích [erase block] a musí s nimi pracovat, stejně jako s mnoha dalšími detaily hardwaru založeném na flash, jsou téměř vždy v návrhu strukturované do záznamů. Nejčastěji používaný takový souborový systém pro Linux je JFFS2 používaný v embedded zařízeních, jako jsou automaty na jízdenky nebo zábavní systémy zabudované do sedadel v letadlech. Více než jednou jsem nasedla do letadla a na takovém zábavním systému viděla chybové hlášení JFFS2 o poškozené flash. (Je smutné, že mnoho tisíc lidí si nyní spojuje bootovací logo tučňáka Tuxe s tím, že během letu na dlouhou vzdálenost nemohli koukat na TV.)
Pro SSD, která exportují blokové rozhraní ve stylu disku – dnes většina SSD pro koncové zákazníky – používá operační systém běžný souborový systém a komunikuje s SSD pomocí tohoto blokového rozhraní (tj. čti blok č. 37 do tohoto bufferu, zapiš tento buffer do bloku č. 42 atd.) Tento systém nicméně stále obsahuje logický ekvivalent do záznamů strukturovaného souborového systému; ten je pouze skryt uvnitř SSD. Firmware, který implementuje vyrovnávání opotřebení, seskupování zápisů a vše ostatní, musí řešit stejné problémy jako do záznamů strukturovaný souborový systém. O tom budeme mluvit dále.
Do záznamů strukturované souborové systémy jsou přirozené pro dnešní flashová úložiště, ale v roce 1990 se zdálo, že mají velký potenciál i pro souborové systémy pro disky. Jak ale všichni víme, takové systémy v našich laptopech ani serverech nepoužíváme. Co se stalo?
Ve zkratce – do záznamů strukturované souborové systémy mají relativně slušný výkon, dokud lze veškeré čištění segmentů – přesuny živých dat mimo segment, aby ho bylo možné znovu použít – provádět na pozadí, když souborový systém není zaneprázdněn „skutečnou“ prací. První větší reakce na práci o LFS [PDF] zjišťuje, že se výkonnost LFS sníží při běžné úrovni využití disku, poměru velikosti paměti k disku a provozu na souborovém systému až o 40 % od nejlepší možné. Ve zkratce – v normálním stavu souborový systém tráví významné množství času čištěním segmentů – přesunem starých dat pryč ze segmentu, aby ho bylo možné znovu použít. Tento problém čištění segmentů byl předmětem výzkumu přinejmenším dalších deset let, ale žádné z řešení nedokázalo přesvědčivě porazit nejmodernější souborové systémy se zápisem na místě při praktické úrovni využití disku. Je to jako porovnávat sběr odpadků [garbage collection] s explicitním čítáním odkazů při správě paměti; když je využité paměti málo a občasný nárůst latence nevadí, pohodlí sběru odpadků převyšuje výkonnostní výhody. Při „vysoké“ úrovni využití disku – stačí 50 % – ale cena za čištění a periodicky se opakující velké latence při čekání, až se uvolní místo, představují problém.
Jak ukázal článek o LFS, klíčem k dobré výkonnosti do záznamů strukturovaného souborového systému je umístit data tak, že se téměř prázdné segmenty vytváří tak rychle, jak jsou spotřebovávány. Propustnost souborového systému pro zápis je omezena tempem, v jakém je schopen vytvořit čisté segmenty. Nejhorší případ je situace, kdy je souborový systém z X % zaplněn a všechny segmenty jsou také zaplněny z X %. Vytvoření jednoho čistého segmentu pak vyžaduje sesbírat živá data z
N = 1/(1 – X)
segmentů (zaokrouhleno nahoru) a zapsat stará data do N – 1 z těchto segmentů. Pro využití disku z 80 % dostáváme:
N = 1/(1 – 0.80) = 1/.20 = 5
segmentů, které je potřeba uklidit. Pokud by segmenty měly 1 MB, museli bychom číst
5 * 800 kB = 4 MB
dat s přeskakováním [seek] a zapsat 4 MB sekvenčně předtím, než bychom byli schopni zapsat 1 MB nových dat. (Poznámka autorky článku pro pedanty: MB/kB se používají jako mocniny 10, ne 2.)
Nejlepší případ je na druhou stranu souborový systém, který má dva druhy segmentů – zcela zaplněné a úplně prázdné. Vzor zapisování pro nejlepší případ je takový, že mění matadata a data v jediném segmentu, takže když se zapisuje nová verze, starou je možné uvolnit a tím se uvolní celý segment. Skutečný stav leží někde mezi těmito dvěma případy. Cílem pro souborový systém strukturovaný do záznamů je vytvořit dvoumodální rozdělení využití segmentů: Většina segmentů by měla být téměř zaplněna nebo téměř prázdná, přičemž plné segmenty by se neměly často měnit. Jak se ukazuje, je těžké toho dosáhnout.
SSD mají další zajímavé omezení: Vyrovnávání opotřebení. I pro nejlepší případ, ve kterém je většina segmentů 100% zaplněna a žádné zápisy nemění jejich data, musí SSD tyto segmenty jednou za čas přesunout, protože musí zápisy rozprostřít na všechny dostupné bloky. To v některých případech přidává přesouvání segmentů navíc a oproti do záznamů strukturovaným souborovým systémům pro disky ještě více ztěžuje dosažení dobré výkonnosti.
Je skvělé, že se výrobci SSD mohou poučit z dvaceti let předchozí práce na do záznamů strukturovaných souborových systémech. Není nicméně jasné, jestli to opravdu dělají. Většina výrobců při vývoji firmwaru pro SSD používá velmi uzavřený přístup – jde o tajnou omáčku, která z levné běžně dostupné flash prodávané s malým ziskem dělá extrémně drahé, spolehlivé a vysoce výkonné úložné zařízení prodávané s velkým ziskem. Někteří výrobci v tomto úkolu zjevně uspěli lépe než jiní. V současnosti výrobci používají strategii obchodního tajemství, aby si svou konkurenční výhodu udrželi – žádají o patenty pro jednotlivé části návrhu, ale celkovou implementaci tají. Zpráva vývojářům souborových systémů je „Prostě nám věřte“ a „Nelámejte si s tím své malé programátorské hlavičky“, kdykoliv se ptáme na další informaci ohledně implementace SSD. S touto strategií se v současnosti nelze příliš dohadovat, ale nesdílení informací s lidmi z vnějšku navozuje (a posiluje) pocit, že stejně tak jsou ignorovány informace od lidí z vnějšku, například dříve publikované akademické práce.
Jedna z největších promeškaných příležitostí založených na poučení ze souborových systémů strukturovaných do záznamů je pomalé přijetí podpory TRIM v SSD. TRIM je příkaz, který blokové zařízení informuje, že určitý rozsah bloků souborový systém již nepoužívá – zjednodušeně jde o volání free() na bloky. Jak bylo popsáno výše, nejlepší výkonnosti se dosáhne, když se jako vedlejší efekt probíhajících zápisů vytvářejí prázdné bloky. Jako jednoduchý příklad vezměme segment, který obsahuje jenom jediný inode a všechna data jeho souboru. Pokud další sada zápisů do souborového systému přepíše všechna data tohoto souboru (a jako vedlejší efekt i inode), pak bude segment úplně volný a souborový systém nemusí přesouvat žádná živá data, aby jej mohl použít znovu. Ekvivalentní akce je u SSD zápis do bloku, do kterého se v minulosti již zapisovalo. Interně SSD ví, že je stará verze bloku nyní volná a že ji může použít, aniž by někam musel kopírovat data.
Do záznamů strukturované souborové systémy mají ale zjevnou výhodu nad SSD z doby před TRIM (tj. v podstatě nad všemi komerčně dostupnými SSD dnes, v září 2009). Tyto souborové systémy totiž ví, že data na disku byla uvolněna, i když nejsou přepsána. Uvažme případ, kdy bude jednosegmentový soubor vymazán: Celý segment je nyní volný, ale nedošlo k žádnému přepisování. Do záznamů strukturovaný souborový systém ví, co se stalo a že má nyní k dispozici jeden volný segment. Všechno, co vidí SSD, je pár malých zápisů do jiných bloků na disku. Z jeho pohledu bloky, které používal nyní vymazaný soubor, stále obsahují drahocenná data, která souborový systém používá, a tak musí tato data přesouvat navěky. Jakmile bylo jednou zapsáno do každého bloku v zařízení, SSD je odsouzeno k nejnižší možné výkonnosti, protože rezervní bloky jsou na minimu a pokaždé se musí přesouvat data, když má být použit nový blok.
Jak jsme viděli, pro dobrou výkonnost souborových systémů strukturovaných do záznamů je klíčová dostupnost volných nebo téměř volných segmentů. SSD bez podpory TRIM o mnoha volných segmentech neví a z toho vyplývá obrovské výkonnostní znevýhodnění, takové, kvůli kterému je šokující, že se vůbec nějaké SSD bez podpory TRIM prodávají. Můj odhad je, že výkonnost SSD se původně testovala pouze na souborových systémech se zápisem na místě (ehm, NTFS) při nízkém celkovém využití těchto souborových systémů (řekněme 70 % nebo méně).
Bohužel TRIM je ve své současné podobě navržen i implementován tak, že se chová neuvěřitelně uboze. Příkazy TRIM nejsou značkové [tagged] a přinejmenším jednomu SSD trvá stovky milisekund příkaz TRIM zpracovat. Vývojáři jádra debatovali o tom, jak přesně implementovat podporu TRIM na Konferenci linuxových instalatérů [Linux Plumbers Conference], na Linux Storage and File System Workshop a v e-mailových konferencích: Jaký je přesně dopad na výkon pro každý TRIM, jakou granularitu by TRIM měl mít, jak často by měl být vysílán a jestli je v pořádku zapomenout nebo zmeškat příkazy TRIM. Podle mě by se stav využitý/volný jednotlivého bloku na zařízení, které umí používat TRIM, měl sledovat tak pečlivě jako u stránek v paměti. Implementace souborového systému může mít formu explicitních synchronních volání alloc()/free() nebo asynchronního sběru odpadu (během kontroly souborového systému nebo preventivního spuštění), ale používané bloky by nám každopádně neměly unikat ze stejných důvodů, z jakých by nám neměla unikat paměť. A k tomu – v ideálním světě – by TRIM měl být vylepšen nebo nahrazen příkazem, který by měl kompletní vlastnosti a ve specifikacích ATA byl dobře navrženým občanem první třídy, nikoliv někam dodatečně připíchnutým hackem.
Toto všechno je samozřejmě bez implementačních detailů od výrobců SSD pouhá spekulace. Možná nějací programátoři firmwaru pro SSD přišli s úplně novými algoritmy pro remapování a shromažďování zápisů, které do záznamů strukturované souborové systémy vůbec nepřipomínají, a výkonnostní charakteristiky a optimalizace, které jsme doteď viděli, tyto souborové systémy připomínají jenom náhodou. Zatím to ale vypadá tak, že chovat se k SSD tak, jako v něm takový souborový systém byl, je dobré obecné pravidlo, když chceme získat dobrou výkonnost. K té bude dlouhodobě klíčem plná podpora TRIM jak na straně SSD, tak na straně souborového systému.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Mezi jeho další veselé příhody patří příhoda vztahující se k algebraickému oboru - teorii grup. V úterý, když vycházely ruské knižní novinky, akademik Kořínek zašel do cizojazyčné literatury. A najednou jindy tak rozvážná kapacita zneklidněla, začal tam nekontrolovaně pobíhat a vykřikoval: "Skupiny jsou nesmysl! Skupiny jsou nesmysl!", ale nikdo ho nebral vážně. Konečně na sebe upoutal pozornost, a aby dodal svým slovům váhu, řekl, že je akademik, jenže odpověď byla ještě pádnější: "To překládal taky akademik!" -- Úvod do matfyzáka
...možná by bylo dobré trošku upravit způsob zobrazení těchto informací – já bych to tam taky nehledal 
nerozumi tomu nikdoHned v první větě je ten termín v originálním znění, takže s neporozuměním by snad problém být neměl.
Ty "zaznamy" mi pri pokusu o zpetny preklad a namapovani na neco co znam spis evokuji slovo "record" nez "log".To mi bylo jasné už při překladu, ale nenašel jsem lepší slovo, které by se dalo použít (do deníku strukturované... zní blbě). Nicméně "do záznamů strukturované" není TAK špatné, aby mě to přesvědčilo, že mám ponechat originální znění.
Souborový systém na bázi špalku. Souborový systém na špalku. Souborový systém připomínající štípání špalků. Mimochodem, slovo "logging" může v AJ znamenat taky kácení lesa (představte si, jak se les mění na metrové dříví). Hmm... kácení souborového systému. Souborový systém pokácený a rozštípaný.
V takových situacích taky dávám přednost anglickým originálům
P.S.: Souborový systém organizovaný jako úhledná hranice metrových špalků?
do záznamů strukturované souborové systémyTo je strašný překlad... (Ale nenapadá mě nic lepšího...
)
Log structured filesystemy se - což je poměrně podivné - vyvinuly z logging filesystemů. Logging (nebo journaling) filesystem je normální filesystem se zápisem na místě ve stylu ext2 nebo FFS s tím, že je k němu připíchnut logging zápisovch operací. (V tomto článku budeme používat termín „journaling filesystem“, aby nedošlo k záměně „logging“ a „log structured“ filesystemu.) Journaling filesystem udržuje stav souborového systému na disku konzistentní tím, že do logu zapíše shrnutí každé zápisové operace na nějaké nonvolatilní úložiště, jako je disk (nebo NVRAM, pokud na to máte peníze), předtím než se změny zapíší na své dlouhodobé umístění ve filesystemu.Jestli ti tohle přijde jako lepší "překlad" do češtiny, tak mě teda ne. Smiř se s tím, že tam, kde z toho nevypadne čistonosoplena, překlady termínů budou - můžete s tím nesouhlasit, můžete proti tomu protestovat, ale to je tak všechno, co s tím můžete dělat.
Ale na druhou stranu, nemám nic proti puritánštějšímu překladu, je to Vaše věc, jakou cestu si zvolíte - hlavně díky Vám za to, že to shrnutí v češtině vyrábíte. Ačkoli nemám problém přečíst si ten materiál v AJ, nějak na ABC zabloudím častěji než na LWN
24.10.2009 14:51
Sleep_Walker
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz