Microsoft představil nové označení počítačů Copilot+. Dle oznámení se jedná se o počítače poskytující funkce umělé inteligence. Vedle CPU a GPU mají také NPU (Neural Processing Unit). Uvnitř představených Copilot+ notebooků běží ARM čipy Qualcomm Snapdragon X Elite nebo X Plus.
Příspěvek na blogu Codean Labs rozebírá zranitelnost CVE-2024-4367 v PDF.js, tj. mj. prohlížeči PDF souborů ve Firefoxu. Při otevření útočníkem připraveného pdf souboru může být spuštěn libovolný kód v JavaScriptu. Vyřešeno ve Firefoxu 126.
Lazygit byl vydán ve verzi 0.42.0. Jedná se o TUI (Text User Interface) nadstavbu nad gitem.
K open source herní konzole Picopad přibyla (𝕏) vylepšená verze Picopad Pro s větším displejem, lepšími tlačítky a větší baterii. Na YouTube lze zhlédnout přednášku Picopad - open source herní konzole z LinuxDays 2023.
Byla vydána (𝕏) nová major verze 17 softwarového nástroje s webovým rozhraním umožňujícího spolupráci na zdrojových kódech GitLab (Wikipedie). Představení nových vlastností i s náhledy a videi v oficiálním oznámení.
Sovereign Tech Fund, tj. program financování otevřeného softwaru německým ministerstvem hospodářství a ochrany klimatu, podpoří vývoj FFmpeg částkou 157 580 eur. V listopadu loňského roku podpořil GNOME částkou 1 milion eur.
24. září 2024 budou zveřejněny zdrojové kódy přehrávače Winamp.
Google Chrome 125 byl prohlášen za stabilní. Nejnovější stabilní verze 125.0.6422.60 přináší řadu oprav a vylepšení (YouTube). Podrobný přehled v poznámkách k vydání. Opraveno bylo 9 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Textový editor Neovim byl vydán ve verzi 0.10 (𝕏). Přehled novinek v příspěvku na blogu a v poznámkách k vydání.
Byla vydána nová verze 6.3 ž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.0.15.
Současné vývojové jádro je 2.6.30-rc2 vydané 14. dubna. Nová architektura 'microblaze', poněkud pozdní začlenění 'vstupní' vrstvy [input layer], nový ovladač pro virtuální síťování a nějaké aktualizace nahrávání firmwaru. A mn10300 a frv přesunuly své hlavičkové soubory z include/asm do arch. To shrnuje to nejvýznamnější, ale nemělo by to nikoho ovlivnit. Zkrácený changelog je v oznámení, všechny detaily vizte v kompletním changelogu.
Během minulého týdne nevyšly žádné stabilní aktualizace, žádné se ani nerevidují.
-- J.R. Okajima to vzdává
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
while(můj_kořenový_adresář_se_neobjevil_a_já_jsem_smutný()) {
wait_on(&objevení_nového_disku);
}-- Alan Cox rozšiřuje bootovací API
-- Linus Torvalds (díky Benu Hutchingsovi)
V typickém vývojovém cyklu Linus Torvalds přetahuje patche z více než 100 stromů do repozitáře hlavní řady. Když se to děje, není neobvyklé, že si stěžuje na to, jak jsou tyto stromy spravovány; většina stížností je na operace změny základního bodu [rebasing] a začleňování [merging]. V nedávné diskuzi v konferenci dri-devel Linus trochu objasnil pravidla správy subsystémového stromu. Jonathan Corbet, autor tohoto článku, se na základě teorie, že možná existuje pár vývojářů, kteří nečtou dri-devel, rozhodl tato pravidla zpřístupnit veřejnosti.
Operace git "rebase" (změna základního bodu) vezme sadu patchů aplikovaných na jeden strom a přepracuje je tak, aby je bylo možné aplikovat na jiný strom. Pokud vývojář(ka) napsal(a) nějaké patche proti 2.6.29, může použít "git rebase", aby se změnily na patche proti 2.6.30-rc1. S gitem lze změnu základního bodu použít také k editaci historie commitů. Jestliže je potřeba něco opravit v patchi, který byl vytvořen před delší dobou, vývojář může (1) odstranit novější patche ze stromu, (2) udělat potřebné změny, (3) změnit základní bod odstraněných patchů podle opraveného patche. Tuto techniku lze použít k tomu, aby se tiše odstranily zahanbující chyby z historie, zlepšily changelogy patchů, opravily konflikty patchů se stromem někoho jiného atd. Jde o něco, co vývojáři používající git jednoduše čas od času dělají.
Se změnou základního bodu je ale spojeno několik problémů. První z nich je, že se mění historie commitů. Když se sérii commitů změní základní bod, každý, kdo se starou historií pracoval, má najednou smůlu. Jestliže je změněn základní bod u značně používaného stromu, všichni vývojáři závisející na tomto stromě jsou nuceni se znovu přizpůsobovat nové realitě. Další problém je, že patche se změněným základním bodem jsou změněné patche; jakékoliv testování, kterého se jim dostalo, již nemusí platit. To je důvod, proč Linus hodně bručí na stromy, u nichž byl zjevně změněn základní bod těsně předtím, než přišel požadavek na jejich přetažení. Změny v těchto stromech pravděpodobně před změnou základního bodu fungovaly, ale po ní již nebyly testovány a nemusí fungovat tak dobře.
Změna základního bodu je nicméně zjevně velmi užitečná technika. Linus vývojářům neříká, že ji nemají používat; ve skutečnosti ji občas podporuje. Klíčové pravidlo, které bylo řečeno, je: Stromu s historií viditelnou jiným stromům základní bod nezměníš. Jestliže vývojář přetáhl strom někoho jiného, u výsledného stromu nelze měnit základní bod, protože to by mohlo poškodit vývojovou historii druhého vývojáře. Podobně jakmile je strom exportován, takže ho mohou používat jiní, nelze mu měnit základní bod.
Na druhou stranu soukromé historii je možné měnit základní bod dle libosti - a tak by se i mělo dít. Jestliže patch zavádí chybu, je lepší ho opravit než odstraňovat nebo přidávat další, opravující patch; výsledkem je čistší historie, která s menší pravděpodobností způsobí problémy lidem, kteří se snaží hledat úplně jiné chyby dělením půlením [bisect]. Jonathan zjistil, že změna základního bodu je často nutná při přidávání značek (například "Odsouhlaseno kým" [Acked-by]) k patchům, které prošly revizí. Když někdo vytváří sadu patchů k jádru hlavní řady, vytváří celou historii, ne jenom konečný výsledek. Zajistit, aby tato historie byla čistá a čitelná, je v zájmu všech.
S tím spojené pravidlo je nicméně to, že stromy, které procházejí změnou základního bodu, by neměly být k dispozici světu:
Jinými slovy, stromy, kterým by se mohl měnit základní bod, by měly zůstat soukromé. Také by neměly obsahovat přetažené stromy jiných vývojářů.
Stojí za to poznamenat, že Linus striktně dodržuje to, co v této oblasti káže. Repozitář hlavní řady akceptuje přibližně 10 000 sad změn každý vývojový cyklus, ale nikdy nemění základní bod. A to je dobře: změna základního bodu hlavní řady by způsobila spoustu problémů v celé vývojové komunitě.
Začleňování [merge] je další místo, kde se správci subsystémů mohou dostat s náčelníkem Tučňáků do konfliktu. "Začlenění" je v gitu podobné jako v ostatních systémech správy kódu; spojí dvě (nebo více) nezávislé linie vývoje do současné větve. Začlenění v gitu se však liší, protože mohou mít více než dvě vstupní větve; Ingo Molnár se proslavil svým "chobotnicovým začleňováním", které spojuje ohromné množství větví v jediné operaci. V téměř všech případech přidává začlenění do repozitáře speciální commit, který ukazuje, že bylo provedeno začlenění, a které soubory, pokud nějaké, měly konflikty.
Začleňování probíhá oběma směry. Když Linus přetáhne subsystémový strom do hlavní řady, výsledkem je začlenění. Je ale běžné, že vývojáři začleňují v opačném směru; přetáhnou hlavní řadu (nebo jiný subsystémový strom vyšší úrovně) do větve obsahující místní linii vývoje. Je přirozené chtít vyvíjet kód proti současnému stavu díla; dává to jistotu, že konečný výsledek bude fungovat se změnami někoho jiného a minimalizuje to pravděpodobnost ošklivého začleňovacího konfliktu v pozdější době.
Nadměrné přetahování hlavní řady (jež dokazují commity začlenění, které vzniknou) nicméně Linuse irituje. Jak to říká on:
Jak každý, kdo pracoval se špičkou repozitáře jádra, ví, stav hlavní řady v náhodně vybraném okamžiku může být, ehm, náhodný. Časté přetahování hlavní řady do vývojové větve do ní tedy přidává určité množství náhodnosti; ta příliš nepomáhá někomu, kdo se snaží rozchodit nějakou vlastnost. Také to zvyšuje šanci, že jiný vývojář, který při dělení půlením skončí uprostřed série, narazí na chybu, kterou nehledá. Linus by tedy byl radši, kdyby vývojáři nepřetahovali vyšší stromy:
Skutečný stav nebývá nicméně tak striktní. Občasné začlenění, aby se drželo tempo s tím, co se děje jinde, může dávat smysl. Co Linus navrhuje, je, aby se taková začlenění prováděla ve specifických bodech vydávání. Přetažení špičky vývojového stromu s největší pravděpodobností nedává smysl, ale lze argumentovat pro přetažení 2.6.29 či 2.6.30-rc1. Udělat to znamená založit vývoj na (snad) relativně stabilním bodě, jehož problémy jsou známy.
Pokušení začlenit hlavní řadu během vývoje může být těžké odolávat; člověk rád ví, jestli je jeho práce alespoň trochu relevantní k současnému stavu kódu. Naštěstí git skutečně snadno umožňuje vytvořit větve k zahození [throwaway branch] a testovat začlenění a integraci na nich. Jakmile je jasné, že věci fungují, testovací větev lze smazat a (rozdělenou [unmerge]) vývojovou větev zaslat do upstreamu.
Podobné pravidlo platí pro začleňování kódu z downstreamu. Přijímající repozitář by měl být v přiměřeně dobře definovaném a stabilním stavu; vývojář pro tento druh začleňování typicky spravuje větev "pro upstream". A kód z downstreamu by měl být "hotový": měl by být v nějakém bodě vydání, ne v náhodném stavu vývoje.
Samozřejmě tato pravidla nejsou absolutní:
Linus si poprvé začal hrát s BitKeeperem v únoru 2002, takže jaderná komunita má nyní za sebou sedm let zkušeností s distribuovanou správou verzí. Pravda ale je, že stále vymýšlíme nejlepší způsob, jak tento konkrétní nástroj využít. Jde o proces, který bude pravděpodobně ještě nějaký čas pokračovat. S tím, jak se jiné projekty přesouvají k využívání nástrojů, jako je git, by jim mohlo stát za to pořádně se podívat na procesy a pravidla, která vyvinula jaderná komunita; mohli by tak zkrátit svoji vlastní dobu učení.
Jeden by si mohl myslet, že souborový systém ext3, vzhledem k tomu, že je již několik let standardem na téměř všech nainstalovaných linuxových systémech, bude velmi dobře vyladěn, co se výkonu týče. Nedávné události nicméně ukázaly, že nějaké problémy s výkonností v ext3 zůstávají, obzvláště v situacích, kdy je voláno systémové volání fsync(). Je ohromující, co se může stát, když se k problému přitáhne pozornost; jádro 2.6.30 bude obsahovat opravy, které zdánlivě eliminují mnoho z latencí, které zažívají uživatelé ext3. Tento článek se dívá na změny, které byly provedeny, včetně překvapivé změny výchozího režimu žurnálování, která byla provedena těsně před vydáním 2.6.30-rc1.
Problém je v krátkosti takový: Souborový systém ext3, když běží v režimu data=ordered, může způsobit dlouhé prodlevy, když nějaký proces zavolá fsync(), aby uložil data na disk. Nejslavnější projev tohoto problému je zatuhnutí systému spojené s Firefoxem, ale týká se i jiných, nejenom Firefoxu. Kdykoliv probíhá dostatečně velké I/O, fsync() může na několik vteřin všechno zastavit. Byla hlášena i zatuhnutí trvající několik minut. Toto chování způsobuje, že od používání fsync() jsou lidé odrazováni a používání Linuxu na desktopu není taková zábava. Zjevně stojí za to to opravit, ale nikdo to několik let neudělal.
Když se Ted Ts'o na problém podíval, všiml si zjevného problému: Data zaslaná na disk pomocí fsync() jsou vložena na konec fronty I/O plánovače za všechny probíhající požadavky. Pokud procesy v systému zapisují hodně dat, může být fronta poměrně dlouhá, takže fsync() trvá dlouho, než doběhne. A než se tak stane, ostatní části souborového systému se mohou zastavit, čímž se nakonec může zastavit většina systému.
První oprava byla označit I/O požadavky vygenerované fsync() bitem WRITE_SYNC, tedy udělat z nich synchronní požadavky. I/O plánovač CFQ se snaží dokončit synchronní požadavky (na jejichž dokončení většinou čeká nějaký proces) před asynchronními (na které nikdo nečeká). Čtení jsou normálně považována za synchronní, zápisy ne. Jakmile jsou požadavky spojené s fsync() označeny jako synchronní, jsou schopné přeskočit před běžné I/O. Díky tomu je fsync() mnohem rychlejší za cenu zpomalení procesů intenzivně provádějících I/O. To je všemi zúčastněnými považováno za dobrý obchod. (Pro pobavení si můžete všimnout, že tato změna je koncepčně podobná patchi I/O priority, který zaslal Arjan van de Ven před nějakým časem; přijetí některých nápadů chce čas.)
Správci blokového subsystému Jensi Axboeovi se tato změna nelíbí s tím, že pravděpodobně způsobí vážné výkonnostní regrese pro některé zátěže. Linus nicméně dal jasně najevo, že patch pravděpodobně bude začleněn, a jestli to CFQ I/O plánovač nezvládne, dojde brzy ke změně výchozího plánovače. Jens by se záležitosti tak jako tak věnoval i nadále, ale tato extra motivace od Linuse tomu neuškodí.
Problém je, jak se ukazuje, to, že WRITE_SYNC ve skutečnosti dělá dvě věci: Vloží požadavek do synchronní fronty o vyšší prioritě a frontu odpojí. "Připojování" [plugging] je technika, kterou bloková vrstva používá k vysílání požadavků ovladači disku v dávkách [bursts]. Mezi dávkami je fronta připojena, takže se v ní požadavky hromadí. Toto hromadění dává I/O plánovači příležitost sloučit vedle sebe ležící požadavky a vyslat je v nějakém rozumném pořadí. Rozumné využívání připojování významně vylepšuje výkonnost blokové vrstvy.
Odpojení fronty kvůli synchronnímu požadavku může v některých situacích dávat smysl; jestliže někdo čeká na dokončení operace, je pravděpodobné, že tato operace do fronty nebude přidávat žádné další vedle ležící požadavky, takže nemá smysl dále čekat. fsync() nicméně není tento případ - volání fsync() naopak obvykle vygeneruje celou sérii synchronních požadavků a pravděpodobnost, že tyto požadavky budou ležet blízko sebe, je poměrně vysoká. Odpojení fronty po každém synchronním požadavku tedy výkon spíše zhorší. Poté, co problém identifikoval, zaslal Jens sérii patchů, která ho opravuje. Jeden z nich přidává novou operaci WRITE_SYNC_PLUG, která naplánuje synchronní zápis bez odpojení fronty. To umožňuje operacím jako fsync() vytvořit sérii operací a frontu odpojit na konci najednou.
Když už byl u toho, opravil Jens pár s tím spojených problémů. Jedním z nich bylo to, že blokový subsystém mohl v některých situacích občas spustit synchronní požadavky za asynchronními. Kód je zde poněkud ošidný, protože může být vhodné nechat projít několik asynchronních požadavků, aby se bránilo jejich kompletnímu vyhladovění. Jens změnil rovnováhu tak, aby se zajistilo, že se synchronní požadavky dostanou ke slovu zavčasu.
Krom toho plánovač CFQ používá pro synchronní požadavky "předvídající" [anticipatory] logiku; po vykonání jednoho takového požadavku frontu zastaví, aby zjistil, jestli se neobjeví vedle ležící požadavek. Myšlenka za tímto chováním je taková, že hlavička disku by v takovém případě byla ideálně umístěna k tomu, aby bylo možné požadavek uspokojit, takže nejlepšího výkonu se dosáhne tím, že se s ní nepohne hned. Tato logika může dobře fungovat u synchronního čtení, ale nepomáhá, když se jedná o zapisující operace generované fsync(). Proto je zde nový interní příznak, který vypíná předvídání, když se vykonávají operace WRITE_SYNC_PLUG.
Linusovi se změny líbily:
Ukazuje se ale, že ještě něco zbývá. Linus si všiml, že zbrzdění je stále pozorovatelné, i když mnohem kratší než dříve, a divil se proč:
Z toho je zjevný závěr, že se stále ještě děje něco dalšího. Linusova hypotéza je, že objem čekajících požadavků na disk je tak velký, že způsobuje zbrzdění, i když se synchronní požadavky dostanou na začátek fronty. Ve výchozím nastavení může požadavek obsahovat až 512 kB dat; poskládejte pár tuctů takových a disku bude nějakou dobu trvat, než se přes ně propracuje. Linux experimentoval s nastavením maximální velikosti (řízeno /sys/block/disk/queue/max_sectors_kb) na 64kB a hlásil, že věci fungovaly mnohem lépe. V době psaní tohoto článku nebyla nicméně výchozí hodnota změněna; Linus naznačil, že by mohlo dávat smysl omezit maximální množství čekajících dat než velikost jednotlivých požadavků. Čeká se na další experimenty.
Je zde nicméně jedna důležitá změna, která je zapotřebí, aby bylo fsync() na ext3 opravdu rychlé: Souborový systém musí být připojen v režimu data=writeback. Tento režim odstraňuje potřebu zapisování datových bloků, které byly na disku před metadaty; v režimu data=ordered je naopak množství dat, která je potřeba zapsat, garancí toho, že fsync() bude vždy pomalejší. Přepnutí na data=writeback tyto zápisy eliminuje, ale zároveň také vypíná vlastnost, díky které se ext3 zdá být robustnější než ext4. Ted Ts'o tento problém trochu zmírnil přidáním stejných pojistek, které vložil do ext4. V některých situacích (jako když je nový soubor přejmenován nad existující soubor), je vynuceno zapsání dat před metadaty. Výsledkem je, že by se měly omezit ztráty dat vyplývající z pádu systému.
Další alternativou k data=ordered by mohl být režim data=guarded navržený Chrisem Masonem. Tento režim by zpozdil aktualizace velikostí, aby se zabránilo problémům s vyzrazením informací. Jde ale o velmi nový patch, který nebude do 2.6.30 připraven.
Další potenciální problém s data=writeback je v tom, že v některých situacích může pád zanechat soubor s bloky, do kterých se ještě nezapsalo. Tyto bloky mohou obsahovat stará data někoho jiného, což je potenciální bezpečnostní problém. Bezpečnost je menší problém než dříve z jednoduchého důvodu, že víceuživatelské linuxové systémy jsou v roce 2009 relativně vzácné. Ve světě, kdy je většina počítačů vyhrazena jedinému uživateli, je potenciál vyzrazení informací v případě pádu mizivě malý. Jinými slovy není jisté, jestli bezpečnost navíc poskytnutá data=ordered stojí za dopad na výkon, který je s tím spojen.
Ted tedy navrhl, že by možná data=writeback mohlo být nastaveno jako výchozí. Tento nápad měl nějaké odpůrce; ne všichni si myslí, že by ext3 v tomto stádiu svého života mělo doznat takto velké změny nastavení. Linus se nicméně těmito argumenty nenechal svést z cesty; začlenil patch, který vytváří konfigurační volbu pro výchozí režim ext3 a nastavil ji na "writeback". To způsobí, že připojování ext3 se tiše přepne do režimu data=writeback s jádry 2.6.30. Linus říká:
Stojí za to poznamenat, že tato výchozí hodnota nic nezmění, pokud je (1) režim dat specifikován při připojení souborového systému nebo (2) do souborového systému pomocí tune2fs zadrátován jiný režim. Také se neuplatní, pokud ji distributoři při konfigurování svých jader přenastaví zpět na "ordered". Přinejmenším někteří z nich se mohou rozhodnout, že nechtějí tento druh změny tlačit ke svým uživatelům. Na odpověď na tuto otázku si budeme muset několik měsíců počkat.
Bylo nebylo, operační systémy se nemusely starat o to, že by se hardware objevoval a mizel v nepředvídatelném okamžiku. U všech periférií, které byly zapojené při bootu, se dalo počítat s tím, že budou zapojeny, až se bude počítač vypínat. Současné systémy takto nefungují; zařízení se objevují a mizí podle toho, jak si uživatel zamane. Různé subsystémy si vyvinuly mechanismy, kterými se vyrovnávají s hardwarem, který z ničeho nic zmizí, tento kód ale bývá specifický pro subsystém a komplexní. Eric Biederman nedávno na tento kód narazil a nelíbilo se mu, co viděl. Tak se rozhodl udělat něco lepšího.
Ericova série patchů začíná tímto pozorováním:
Eric také poznamenává, že růst v oblasti PCI zařízení vyměnitelných za chodu bude zvyšovat počet subsystémů a ovladačů, které budou muset být na tuto eventualitu připraveny. Místo šíření kódu specifického pro vyjímatelná zařízení do dalších částí jádra by rád vytvořil jeden centrální, dobře podporovaný mechanismus.
Problém, na který se Eric konkrétně dívá, je tento: Co se stane s otevřenými popisovači souborů, když zdroj pod nimi zmizí? Bez ohledu na to, jestli je zdroj fyzické zařízení, modul nebo něco úplně jiného, jádro musí udělat správnou věc, když již popisovač neukazuje na něco platného. Ericovy patche vytvářejí novou infrastrukturu, která každému subsystému umožňuje snadno odmítnout přístup k popisovači souboru spolehlivějším a robustnějším způsobem než dříve.
První problém, který se objeví, je - jako vždy - mmap(). Jestliže je do adresového prostoru procesu namapováno již neexistující zařízení, mohou se stát zajímavé a nepříjemné věci. Eric odpovídá novou funkcí:
void remap_file_mappings(struct file *file,
struct vm_operations_struct *vm_ops);
Volání remap_file_mappings() najde všechny oblasti virtuální paměti [virtual memory area, VMA] spojené s daným souborem file. Všechny mapované stránky jsou odmapovány, což je znepřístupní procesu, který je mapoval. Operace spojené s VMA budou nahrazeny pomocí vm_ops; tyto operace budou běžně revoked_vm_ops, které jednoduše vrací chybu sběrnice pokaždé, když se proces pokusí přistoupit k některé z dotčených stránek.
Jádro zjevně také musí blokovat všechny ostatní operace - read(), write(), ioctl() atd. - které lze s popisovačem souboru provést. Způsobem, jak to zařídit, je samozřejmě nahradit strukturu file_operations spojenou se souborem. Zajistí to tato funkce:
int fops_substitute(struct file *file, const struct file_operations *f_op,
struct vm_operations_struct *vm_ops);
Lze si představit, že tato funkce bude poměrně jednoduchá, něco jako:
file->f_op = f_op; remap_file_mappings(file, vm_ops);
Popravdě je ale tato záležitost trochu komplikovanější. Pro začátek mohou běžet vlákna se starými souborovými operacemi a některá z nich mohou čekat na události, které - nyní - nemohou nastat. Aby ovladačům v této situaci pomohly se odblokovat, přidávají Ericovy patche do struct file_operations novou položku:
int (*awaken_all_waiters)(struct file *filp);
Tato funkce by měla způsobit, že se každé vlákno čekající na daný soubor probudí a všimne si, že se svět změnil.
Další problematický bod je ten, že nyní, když byly vyměněny souborové operace, nemá ovladač níže možnost poznat, že byly uzavřeny všechny popisovače souboru. To je vyřešeno čekáním na situaci, kdy žádný známý uživatel nepoužívá staré souborové operace, a následným zavoláním release() přímo z fops_substitute(). To vede k záludné otázce, co se stane, pokud se nějaké vlákno nikdy neprobudí a počet uživatelů nikdy neklesne na nulu; v současném patchi se fops_substitute() v takové situaci jednoduše zasekne.
Nicméně předtím, než se toho začneme obávat, je zde problematičtější záležitost v tom, že jádro nemá ponětí, kolik uživatelů struktury file_operations existuje. Eric tedy musel přidat mechanismus počítání odkazů. Podle nového způsobu musí jakýkoliv jaderný kód ohraničit volání file_operations daného souboru do:
int fops_read_lock(struct file *file); void fops_read_unlock(struct file *file, int revoked);
Návratová hodnota fops_read_lock() (kterou Eric neměnně nazývá fops_idx) je nenulová, pokud byl přístup k souboru již odmítnut; musí být předána odpovídajícímu volání fops_read_unlock(). Největší část série patchů je prokousání se přes jádro kódu VFS a přidávání zamykání okolo všech přístupů k file_operations. To je spousta malých změn v kódu, které je potřeba udělat na mnoha místech.
I tak se to vyplatí: Obsluha souborů se zrušeným přístupem v různých ostatních subsystémech může být vytržena a nahrazena novým, obecným kódem. Změny v souborovém systému /proc například ponechávají kód o téměř 400 řádek kratší. Jádro se tedy zmenší a nový kód by se štěstím měl být robustnější a spravovatelnější.
Tento mechanismus je užitečný v situacích, když zařízení mizí, ale v dohledu je také větší cíl. Dlouho již existuje požadavek na obecné systémové volání revoke(), které by odpojilo všechny otevřené popisovače k danému souboru nebo zařízení. Bylo by možné ho použít například k implementaci nějakého druhu bezpečnostní klávesové zkratky [secure attention key], zabití všech procesů, které mají otevřené popisovače souborů zařízení konzole. revoke() by také bylo užitečné pro nucené odpojování souborových systémů. Je to užitečný nápad s pouze jedním problémem: revoke() je opravdu složité. Nikdo ještě nepřišel s implementací, která vypadá dostatečně kompletně a robustně na to, aby byla vložena do jádra.
Ericova sada patchů se do tohoto stavu také nedostala. Reprezentuje ale další útok na problém za použití přístupu, který, jak se shoduje většina vývojářů, představuje způsob, jak je potřeba revoke() implementovat. Postupem času by se mohla vyvinout do obecného řešení, které se vývojářům léta vyhýbalo.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
26.5.2009 06:43
Fluttershy, yay! | skóre: 92
| blog:
Další alternativou k data=ordered by mohl být režim data=guarded navržený Chrisem Masonem.
^_^
že zaznamen8v83 zpožděníAutor nebo překladatel měl problém s přepínáním klávesnice
A hned v další větě:
Z toho je zjjvný závěr,Další odstavec:
Tento režim odstraňuje potřebu zapisování datových bloků byly na disk před metadaty„Byly“ je tam zřejmě navíc.
Autor nebo překladatel měl problém s přepínáním klávesniceKorektor.
Z toho je zjjvný závěr,Tentokrát autor i korektor, já napsal zejvný
„Byly“ je tam zřejmě navíc.Robert asi tentokrát chvátal...
. Klobouk dolu před Jirkou - já už ani nevím, jak jsem to dělal, když jsem to ještě překládal sám...
Uživatelský slovník nemusí být jenom jeden. Můžete mít slovník pro každou aplikaci nebo obor nebo stupeň odbornosti zvlášť.
Chápu, že není dobré kdejaký jednoúčelový patvar přidat do slovníku. Ale pokud vám standardní slovník vyhodí 50 neznámých slov, z čehož jsou skutečné překlepy jen 3, tak je škoda nevyužít nástrojů, které máme. Až budete kontrolovat příští verzi, tak už vás těch 47 novotvarů obtěžovat nebude.
Já na gettextové překlady používám něco takového:
27.5.2009 11:16
msgexec -i $< sed 'a\' | \
aspell --lang=cs --encoding=utf-8 list | \
aspell --lang=en --encoding=utf-8 list | \
sort -u >badtranslationlist
Myšlenka je vytáhnout z kódu obsahový text (ve vašem případě to budou textové uzly a hodnoty atributů alt a title; lze použít parametr aspellu --mode=html), který zkontrolujeme proti českému slovníku a zbytek proti anglickému. Výsledek setřepeme do seřazeného seznamu.
Takový seznam si pak pozorně přečteme a chybná slova v původním textu opravíme. Ustálené novotvary můžeme připadat do vlastního slovníku a ten pak použít při další kontrole. Tento postup opakujeme, dokud soubor badtranslationlist obsahuje slova, která se nám nelíbí.
Když se tak hromadně opravuje, tak bych přidal zajímavé slovo "zaznamen8v83".
Jinak super seriál, díky za překlady. Dnešní citát o samohláskách mě opravdu dostal.
Tak opravu beru zpět (už tu je), poděkování ne :)
fsync() nikdy nenarazil, zato s ním (nebo něčím, co se projevuje velmi podobně) už nějakou dobu válčím u XFS. Dokonce jsem už rezignoval a na velké filesystémy (stovky GB), na kterých hodlám mít image disků virtuálních strojů pro VMware, raději používám JFS.
Řekl bych, že ten problém se projevuje už nyní. Jakmile máte velkou diskovou cache, plnou nezapsaných dat a pak zavoláte fsync, tak data synchronizovaného souboru se umístí na konec fronty, ale de facto se vynutí vypláchnutí celé cache. A to je záležitost, která s dnešními obludně velkými paměťmi (a tedy i cachí) trvá znatelně dlouho.
Když jsem měl v počítači 32 MB RAM, tak disková cache zabírala několik megabajtů, disk byl schopen sekvenčního zápisu kolem 11 MB/s, takže (f)sync trval teoreticky nejdéle sekundu (u rozkouskovaného zápisu to mohlo být tak 5 sekund). To vzhledem k tehdejší rychlosti procesorů a častému swapování jste ani nepostřehl.
Dneska mám disk, který sekvenčně dá 50 MB/s, a v diskové cache třeba právě teď mám 153 MB. To už představuje teoretické minimální 3 sekundy. Tedy trojnásobné zhoršení.
Kdybych měl moderní stroj, tak mi disk dá 100 MB/s, ale pokud jej taky adekvátně zatížím (nějaké to desktopové prostředí, Firefox, Eclipse, Evolution, …), tak disková cache bude zabírat třeba gigabajt a vylití bude trvat alespoň 10 sekund.
Dneska mám disk, který sekvenčně dá 50 MB/s, a v diskové cache třeba právě teď mám 153 MB. To už představuje teoretické minimální 3 sekundy. Tedy trojnásobné zhoršení.
Kdyby šlo o tři sekundy, tak to neřeším. Problém, o kterém jsem se zmiňoval u XFS, se projevuje tak, že při 100 MB nezapsaných dat trvá provedení příkazu sync 30-60 sekund. Podobně třeba po vypnutí VMware virtuálního stroje následovala při troše smůly desítky sekund trvající prodleva, během které jeho UI nereagovalo a stejně tak všechno ostatní, co se snažilo přistupovat k disku (předpokládám, že VMware volá po vypnutí virtuálního stroje fsync() na image virtuálního disku). Mountováním s nobarrier se to zlepšilo, ale jen zhruba na polovinu, řešením byl teprve přechod na JFS.
To, co popisuji já, je problém blokové vrstvy. Vy jste měl spíš problém se souborovým systémem. Já XFS vůbec neznám, takže těžko můžu radit.
Tak mně napadá, jestli položka cached, kterou vypisuje free, je jen bloková cache nebo obsahuje i paměť alokovanou pro souborové systémy?
Kdyby to byla jen bloková cache (jak si myslím), tak co je v ní, už dávno prošlo (V)FS, takže její vylití by mělo být omezeno jen výkonností plánovače blokového I/O. Takže pokud ta cache neobsahuje hromadu drobných synchronních požadavků, které by mohly ucpat sběrnici z řadiče do disku režií ATA protokolu a donutit disk k neefektivnímu seekování, tak by měl jet disk na plno a cache by se měla vyprázdnit za pár sekund.
Tyhle potíže pozoruji, když mám CD-RW i pevný disk na stejném IDE kanálu, a cdrecord intentizvně komunikuje s CD mechanikou (třeba při záhájení nebo dokončení vypalování nebo při rychlém mazání TOC). Pak se nemám jak dostat k disku.
Tak mně napadá, jestli položka cached, kterou vypisuje free, je jen bloková cache nebo obsahuje i paměť alokovanou pro souborové systémy?
Tohle číslo je z tohoto pohledu celkem nezajímavé, protože to je veškerá disková cache, z níž většinu obvykle většinu tvoří data, která jsou načtena do cache, ale na disku jsou aktuální, takže je není potřeba zapisovat. Pro to, o čem se bavíme, je směrodatnější spíše hodnota Dirty v /proc/meminfo.
Tyhle potíže pozoruji, když mám CD-RW i pevný disk na stejném IDE kanálu, a cdrecord intentizvně komunikuje s CD mechanikou (třeba při záhájení nebo dokončení vypalování nebo při rychlém mazání TOC). Pak se nemám jak dostat k disku.
Tomu bych se samozřejmě nedivil, ale tohle není ten případ. Ty problémy jsem měl na počítači, kde disk i CD-RW mechanika byly na SATA řadiči (navíc na PCI-E sběrnici) a většinou se CD-RW mechanika vůbec nepoužívala. A nešlo jen o jeden počítač, u některých šlo dokonce o SCSI disk. Společným znakem byl 64-bitový procesor (tím ovšem nechci naznačovat, že na 32-bitových se to dít nemůže) a mám pocit, že s vícejádrovými procesory to bylo trochu výraznější (ale to nemám podloženo měřením).