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.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
Tento článek je překlad z LWN.net.
Jádro 2.6.31 je venku, Linus ho vydal 9. září. Některé z významnějších vlastností zahrnují podporu čítačů výkonnosti, upozorňovací infrastrukturu „fsnotify“, jaderné nastavování režimu pro čipové sady radeon, nástroj kemleak, podporu znakových zařízení v uživatelském prostoru, podporu USB3 a mnoho dalších. Jako vždy můžete více vyčerpávající seznam nalézt na stránce KernelNewbies 2.6.31.
Vydání předcházela předverze 2.6.31-rc9 vydaná 5. září.
Současné stabilní jádro je 2.6.30.6 vydané (společně s 2.6.27.32 2.6.27.33) 8. září. Obě obsahují dlouhý seznam oprav, z nichž mnoho je v subsystému KVM.
-- Andrew Morton (díky Nikanthovi K)
-- Ingo Molnár
Oznámení, které zaslal Joel Becker ohledně svého plánu začlenění ocfs2 do 2.6.32, zahrnovalo zmínku o tom, že systémové volání reflink() bude začleněno společně se změnami ocfs2. Volání reflink() vytváří odlehčenou kopii – oba soubory sdílejí stejné bloky v režimu kopírování při zápisu. Finální podoba API reflink() je tato:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
int reflink(const char *oldpath, const char *newpath, int preserve);
int reflinkat(int olddirfd, const char *oldpath,
int newdirfd, const char *newpath,
int preserve, int flags);
Volání reflink() způsobí, že newpath bude vypadat jako kopie oldpath. Pokud je hodnota preserve REFLINK_ATTR_PRESERVE, pak je do nového souboru zkopírován kompletní stav bezpečnostních informací oldpath; to je privilegovaná operace. V opačném případě (tedy preserve je REFLINK_ATTR_NONE) newpath obdrží nové bezpečnostní informace, jako by šlo o zcela nový soubor. Varianta reflinkat() přidává možnost dodat počáteční adresáře pro relativní cesty a příznaky podobné těm u ostatních systémových volání *at(). Více informací vizte v dokumentačním souboru na začátku patche reflink().
Joelův patch přidává podporu pro reflink() do souborového systému ocfs2; není jasné, jestli se podpora pro reflink() v 2.6.32 objeví i pro ostatní souborové systémy.
Opakovaně se objevující hádky na linux-kernel se většinou zaměřují na velmi důležité záležitosti – jako kde by měl být připojen debugfs. Oficiální názor je, že patří do /sys/kernel/debug, ale jsou neustálé problémy se zvlčilými vývojáři, kteří ho připojují na neoficiální místa jako do /debug. Greg Kroah-Hartman obhajuje /sys/kernel/debug s poznámkou, že debugfs je jenom pro jaderné vývojáře; není důvod, aby se o něj zajímali uživatelé.
Samozřejmě až na to, že je. Rostoucí využívání frameworku ftrace způsobuje, že je debugfs čím dál tím zajímavější mimo kruhy vývojářů jádra. To vedlo Stevena Rostedta k návrhu:
Steven by rád nový virtuální souborový systém pro stabilní jaderné ABI, se kterým se pracuje snáze než se sysfs a který by šlo připojit na místo, jehož název je přátelštější pro prsty, které k němu vypisují cestu. Reakcí na tento návrh bylo málo; někdo pravděpodobně bude muset zaslat patch, aby se rozproudila skutečná diskuze.
Chris Mason zaslal novou verzi patche pro režim data=guarded v ext3. Ochranný [guarded] režim zajišťuje, že se datové bloky uloží na disk před změněnými metadaty, které se na tyto bloky odkazují. Cílem je poskytnout výkonnostní zisky režimu data=writeback a přitom se vyhnout potenciálnímu vyzrazení informací (po pádu), které u tohoto režimu může nastat. Chris v minulosti zmínil, že by tento kód rád začlenil do 2.6.32; v nejnovějším zaslání nicméně připouští, že je stále potřeba udělat nějakou práci, takže to možná nebude hotovo včas.
Jak se před časem psalo, Con Kolivas se nedávno znovu objevil s novým plánovačem CPU nazvaným „BFS“. Tento plánovač, jak říká Con, řeší problémy, které sužují plánovač CFS v hlavní řadě; největším z nich je podle všeho nadřazování „škálovatelnosti“ nad použití na běžných desktopových systémech. BFS si dává za cíl zaměřit se zpět na systémy na uživatelské úrovni a možná docílit toho, aby bylo v jádře podporováno několik plánovačů.
Od té doby zareagoval autor CFS Ingo Molnár sérií benchmarků, které oba plánovače porovnávají. Testy obsahovaly dobu překladu jádra, výkonnost rour, výkonnost zasílání zpráv a test zpracování online transakcí; zaslal grafy, ve kterých je ukázáno, jak se oba plánovače chovaly v jakém testu. Ingův závěr: Bohužel, jak lze vidět z grafů, s BFS na tomto stroji nevidím žádné zlepšení výkonnosti. Ve skutečnosti to bylo právě naopak: BFS se obecně chovalo hůře než plánovač v hlavní řadě.
Conovu odpověď lze nejlépe popsat jako „mávnutí rukou“:
Pokud může autor článku, Jonathan Corbet, řici, tyto námitky k výsledkům jsou podobné těm, které bylo možné slyšet i jinde: Ingo pro své testy vybral atypický stroj a tyto testy v žádném případě neměří výkonnost plánovače na desktopu. Cyničtější pozorovatelé, zdá se, věřili tomu, že Inga zajímá obrana současného plánovače víc než vylepšení zkušeností uživatelů na desktopu.
Vybraný stroj byl podle měřítek „desktopů“ rozhodně high-end:
Mnoho lidí si myslelo, že takový stroj není typický linuxový systém. To může být pravda – dnes. Ale jak (mezi jinými) upozornil Ingo, je důležité při návrhu jaderných subsystémů myslet trochu dopředu:
Částečně v reakci na tuto kritiku nicméně Ingo zkusil své testy znovu na systému s jedním čtyřjádrem, což je stejný typ systému jako Conův stroj. Výsledky byly přibližně stejné.
Použitý hardware nicméně není relevantní, pokud benchmarky netestují charakteristiky desktopu, o které se uživatelé starají. Nejsledovanější veličinou je latence: Jak dlouho trvá, než se spustitelný proces dostane ke své práci. Pokud jsou latence příliš velké, proudy audia či videa začnou přeskakovat, ukazatel se bude opožďovat za pohybem myši, rolování bude trhané a hráči Maelstromu přijdou o lodě. Mnoho z Ingových původních testů souviselo s latencí a v druhém kole přidal několik dalších. Zdá se tedy, že benchmarky se přinejmenším snažily měřit relevantní veličinu.
Výsledky benchmarků ale nejsou totéž jako lepší zkušenosti s desktopem a mnoho uživatelů hlásí „plynulejší“ desktop, když používají BFS. Na druhou stranu dělat významné změny plánovače založené na subjektivních „pocitech“ je jistá cesta k potížím: Pokud není možné změřit zlepšení, nejenom že je riziko, že žádný problém nebude opraven, ale navíc je významné riziko, že se pro další uživatele zavlečou výkonnostní regrese. Musí být nějaký relativně objektivní způsob, jak soudit výkonnost plánovače.
Preferovaný způsob, který používají správci plánovače, je identifikovat příčiny latence a ty opravit. Jaderná infrastruktura pro identifikaci problémů s latencí se během posledního roku či dvou významně zlepšila. Jeden užitečný nástroj je latencytop, který sbírá data o tom, co zpožďuje aplikace, a výsledky předává uživateli. Sledovací framework ftrace je také schopen shromáždit data o zpoždění mezi tím, kdy je proces probuzen a kdy se skutečně dostane k CPU; vizte tento příspěvek Frederica Weisbeckera, kde najdete informace o tom, jak lze tato měření provést.
Jestliže v linuxovém plánovači zůstávají skutečné problémy s latencí – a hlášení „BFS je lepší“ je dost na to, aby se dalo říct, že ano – pak použití dostupných nástrojů k jejich popisu se zdá být postup správným směrem. Jakmile je problém lépe pochopen, je možné hledat řešení. Dost možná lze upravit plánovač v hlavní řadě tak, aby tyto problémy zmizely. Nebo bude možná nutný radikálnější přístup. Bez pochopení problému – a s tím spojené schopnosti ho měřit – se ale pokusy o opravu zdají být poněkud riskantní výstřel do tmy.
Ingo přivítal Cona zpět ve vývojové komunitě a navrhl mu, aby pomohl vylepšit linuxový plánovač. To se však pravděpodobně nestane. Conův způsob práce nikdy s vývojovou komunitou dohromady nešel a Con sám vykazuje jenom málo znaků toho, že by chtěl tento stav změnit. To je nešťastné; je to talentovaný vývojář, který by toho mohl udělat hodně pro důležitou komunitu uživatelů. Přijetí současného plánovače CFS je přímým výsledkem jeho dřívější práce, i když nenapsal kód, který byl skutečně začleněn. Obecně ale vylepšování Linuxu vyžaduje spolupráci s komunitou vývojářů; pokud chybí snaha udělat to efektivně, je velmi omezeno to, čeho vývojář může dosáhnout.
(Vizte také benchmarky Franse Popa, které ukazují rozhodně smíšené výsledky.)
Od té doby, co se strom staging objevil v červnu 2008, udělal velký pokrok. Začněme tím, že se v říjnu 2008 přesunul do hlavní řady; také nasbíral více než 40 různých ovladačů různých druhů. Staging je pokračování Projektu ovladač pro Linux [Linux Driver Project] v tom, že jeho cílem je sbírat ovladače a další „samostatný“ kód, jako jsou například souborové systémy, který ještě není připraven pro hlavní řadu. Nikdy ale nebyl myšlen jako smetiště pro mrtvý kód, jak to řekl Greg Kroah-Hartman v nedávném hlášení o stavu [status update]. Kód, který se nezlepšuje, aby mohl být přesunut do hlavní řady, bude ze stromu odstraněn.
Část kódu, který je – alespoň v současnosti – navržen k odstranění, obsahuje i nějaké poměrně známé ovladače včetně toho od Microsoftu, který byl vydán s velkou fanfárou v červenci. Po masivním pročišťování, které vyústilo ve více než 200 patchů, jež měly kód dostat do napůl příčetné podoby jaderného stylu psaní kódu, řekl Greg, že kód bude přibližně během šesti měsíců odstraněn:
Microsoft rozhodně není v Gregově zprávě osamocen – zpráva přibližuje stav stromu před nadcházejícím začleňovacím oknem 2.6.32 – protože ovladače několika dalších velkých firem jsou přibližně na stejné lodi. Mezi jinými v hlášení byly zmíněny ovladače pro hardware Android (staging/andriod), hardware Management Engine Interface (MEI) Intelu (staging/heci). Oba budou odstraněny, android v 2.6.32, heci v 2.6.33 (pravděpodobně). Ten druhý poskytuje krásný příklad toho, jak se nevyvíjí ovladače pro Linux:
Gregova dlouhá zpráva se nedívá jenom na ovladače, které mohou být odstraněny; také se dívá na ty, které za sebou mají nějaký pokrok a které by se měly přesunout do hlavní řady, stejně jako na nové ovladače. Seznam ovladačů, na kterých nikdo nepracuje, je ale přibližně stejně dlouhý jako druhé dva seznamy dohromady, což zjevně není zrovna optimální.
Pravděpodobně aby zjistil, jestli to lidé čtou celé, rozhodil Greg do jinak suchého shrnutí několik vtipů. U ovladačů me4000 a meilhaus poznamenává, že není důvod v nich pokračovat kromě možnosti pozorovat lidi od RT svíjet se, když se snaží rozklíčovat složité zamykání a logiku překladu (což se rozhodně počítá, levná zábava je vždy dobrá ;-)
Také poznamenává, že několik ovladačů je v kategorii neaktivních, ale jsou poměrně blízko k tomu, aby byly začlenitelné. Navrhuje, že vývojáři, kteří hledají způsob, jak přispět, by měli uvážit ovladače jako asus_oled (OLED display Asus), frontier (řadič Frontier digital audio workstation), line6 (efektový procesor PODxt Pro), mimio (interaktivní tabulce Mimio Xi) a panel (LCD/keypad pro paralelní port). Všechny by mělo být relativně snadné dostat na úroveň potřebnou pro začlenění do hlavní řady.
Do 2.6.32 je také přidáno slušné množství nových ovladačů včetně ovladačů Hyper-V od Microsoftu (staging/hv) zmíněných dříve, stejně jako ovladačů pro sběrnici VME (staging/vme), subsystém pro průmyslové I/O (staging/io) a několik dalších bezdrátových ovladačů (VIA vt6655 a vt6656, Realtek rtl8192e a Ralink 3090). Také byl přidán další COW ovladač: Pseudoblokové zařízení Cowloop s kopírováním při zápisu [copy-on-write, COW] (staging/cowloop).
Také byly zmíněny dva z projektů Jevgenije Poljakova – chybně uvedené v sekci „nové ovladače“, přestože byly přidány do 2.6.30. Síťové blokové zařízení pro distribuované úložiště [distributed storage, DST] (staging/dst), o kterém Greg poznamenává, že je možná mrtvé, je kandidátem na odstranění, zatímco distribuovaný souborový systém POHMELFS (staging/pohmelfs) je z větší části vyvíjen mimo strom. Jevgenij souhlasí, že DST v hlavní řadě být nemusí, ale uvažuje nad přesunutím POHMELFS ze staging do fs/. Vzhledem k tomu, že se POHMELFS bude razantně měnit, pravděpodobně se ze staging během několika dalších vydání jádra stěhovat nebude.
Greg také žádal, aby se zapracovalo na různých ovladačích, na kterých byl během několika posledních měsíců odveden kus práce. Zmíněni byli Bartlomiej Zolnierkiewicz za svou práci na ovladačích bezdrátových zařízení rt* a rtl* (která ho umístila na první místo seznamu nejaktivnějších vývojářů 2.6.31) a Alan Cox za práci na ovladači
Ve vlákně vystoupil přinejmenším jeden vývojář s tím, že bude pracovat na neaktivních ovladačích (asus_oled). Krom toho Willy Tarreau zmínil, že slyšel o dalším, který pracuje na panel, takže Gregovi řekl: To dokazuje, že strom staging, zdá se, funguje.
Ve shrnutí se zdá, že strom staging dělá přesně to, co Greg a další předvídali. Přidání staging do hlavní řady zviditelnilo a zpřístupnilo ovladače v něm, což vedlo k slušnému množství práce, která byla věnována jejich pročištění, takže některé z těchto ovladačů se nakonec ze staging přesunuly do hlavní řady. Jiné ovladače pravděpodobně upadnou do příkopu, ale lze očekávat, že je Greg uvítá zpět, pokud se ukáže někdo, kdo by na nich chtěl pracovat. Jejich kód ani tak rozhodně neutrpěl jakýmikoliv opravami, ke kterým se jaderní hackeři dostali. Tyto změny budou čekat na každého, kdo by ten kód chtěl zase sebrat, i když už nebude součástí staging.
Originál tohoto článku pro LWN.net napsala Valerie Aurora (dříve Hensonová).
Jasně, programátoři (obzvlášť programátoři operačních systémů) milují specifikace. Čistá, dobře navržená rozhraní jsou klíčovým prvkem škálovatelného vývoje softwaru. Co je to ale na souborových systémech, POSIXu a tom, kdy má být garantováno, že jsou data na trvalém úložišti, co z nás všech dělá POSIXové fundamentalisty? Nedávná rozepře o fsync()/rename()/O_PONÍCI byla nejrozhádanější, jakou si za poslední dobu pamatuji, ale rozhodně nebyla pro diskuze spojené s fsync() atypická. V tomto článku prozkoumáme vztah mezi vývojáři souborových systémů, standardem POSIX pro I/O a lidmi, kteří prostě chtějí ukládat svá data.
Jako mnoho praktických rozhraní (včetně HTML a TCP/IP) bylo i POSIXové rozhraní pro souborové systémy nejprve implementováno a pak teprve specifikováno. UNIX byl napsán počátkem roku 1969; první vydání specifikací POSIX pro UNIXové rozhraní pro souborové I/O (IEEE Standard 1003.1) bylo uvedeno roku 1988. Před UNIXem byl přístup aplikací k permanentnímu úložišti (například rotujícímu bubnu) rozhodně záležitost specifická jak pro aplikaci, tak pro hardware. Na záznamech založené souborové I/O bylo běžným paradigmatem, což se přirozeně vyvinulo z děrných štítků, různé druhy souborů byly obsluhovány různě. Nové rozhraní bylo navrženo několika pány (Ken Thompson, Dennis Ritchie a dalšími), kteří se poflakovali okolo svého nového stroje a psali operační systém, který měl zjednodušit, ehm, psaní dalších operačních systémů.
Jak dnes víme, nové rozhraní pro I/O se stalo hitem. Ukázalo se, že je přenositelné, všestranné a prosté, což zjednodušilo vývoj modulárního softwaru. Samozřejmě nebylo v žádném případě perfektní: Postupem času se objevilo několik bradavic, z nichž mnohé předtím, než bylo rozhraní vytesáno do specifikace POSIX, nebyly odstraněny. Jedním příkladem jsou pevné odkazy na adresáře, které umožňují vytvoření zacykleného adresáře – adresáře, který obsahuje sebe sama – a následné odpojení tohoto adresáře ze struktury souborového systému; to vede na alokované, ale nepřístupné soubory. Ukládání času posledního přístupu – atime – mění každé čtení na malý zápis. A nezapomeňme apokryfický citát Kena Thompsona, kterého se ptali, jestli by něco udělal jinak, kdyby UNIX navrhoval dnes: Kdybych to měl udělat znovu? Hmm… asi bych ,creat‘ napsal s ,e‘ na konci. (Zde se mluví o systémovém volání creat(), které vytváří nový soubor.) Celkově ale bylo UNIXové rozhraní pro souborový systém obrovský úspěch.
Postupem času se okolo standardní sady souborových I/O rozhraní vytvořily více či méně přenositelné přídavky; příležitostně byly standardizovány a přidávány do kánonu – jako zjevení moderních proroků. Namátkou některé příklady, které mě napadají jako první, zahrnují pread()/pwrite(), přímé I/O, předalokaci souboru, rozšířené atributy, seznamy pro řízení přístupu (ACL) všech tvarů a barev a obrovské pole připojovacích voleb. I když jsou tyto přídavky často diskutabilní a implementované nekompatibilními způsoby, ve většině případů se nikdo nesnaží oponovat jim z důvodu, že nejsou přítomny ve standardu napsaném roku 1988. Podobně se většinou příliš nediskutuje o odmítání některých méně smysluplných detailů POSIXu, jako je například výše zmíněná vlastnost pevných odkazů na adresáře.
Proč tedy otázka, kdy má být garantováno, že data souborového systému jsou „na disku“, mění vývojáře souborových systémů v pedantické POSIX citující fundamentalisty? Fundamentálně (ha) problém spočívá v tomto: Čekat na to, až se data opravdu dostanou na disk, před návratem ze systémového volání, znamená prohrát ve hře o nejvýkonnější souborový systém. Jako nejextrémnější příklad vezměme původní synchronní verzi UNIXového souborového systému, který často využíval pouze 3-5 % propustnosti disku. Téměř všechna zlepšení výkonnosti souborového systému od té doby byla hlavně výsledkem skládání zápisů tak, aby je bylo možné alokovat a zapsat jako skupinu. Jako vývojáři souborových systémů se tedy podíváme na každou smyčku ve fsync() a vykroutíme se z ní.
Naštěstí pro vývojáře souborových systémů je specifikace POSIX tak minimalistická, že téma, jak by se souborový systém měl zachovat po pádu systému, vůbec nezmiňuje. Konec konců původní souborové systémy ve stylu FFS (např. ext2) mohou teoreticky po pádu ztratit všechna data a přesto POSIXu vyhovují. Je tedy ironické, že jako vývojáři souborových systémů věnujeme 90 % svého myšlení tomu, aby se souborový systém rychle zotavil po pádu. Není divu, že jsou uživatelé souborových systémů naštvaní, když definujeme, že metadata souborového systému jsou dostatečně důležitá, aby musela zůstat konzistentní, kdežto data ne – o svá se staráme dobře. Vývojáři souborových systémů se nicméně velkomyslně shodli na tom, že po návratu z fsync() a pouze z fsync() a pouze na souborovém systému připojeném se správnými připojovacími volbami bude daný soubor k dispozici, pokud systém následně spadne.
Zároveň platí, že fsync() je často dražší, než je absolutně nutné. Nejsnazší způsob, jak implementovat fsync(), je vynutit všechny čekající zápisy souborového systému bez ohledu na to, jestli se jedná o žurnálovací souborový systém, souborový systém s COW (kopírováním při zápisu) nebo souborový systém bez jakéhokoliv mechanismu pro obnovu po pádu. To proto, že je velmi obtížné zpětně mapovat z daného souboru na špinavé bloky souborového systému, které je potřeba zapsat na disk, aby byl vytvořen konzistentní souborový systém, který dané změny obsahuje. Pro příklad blok, který obsahuje bitovou mapu pro nově alokované bloky dat souboru, mohl být také změněn pozdější alokací jiného souboru, což následně vynucuje, abychom zapsali nepřímé bloky ukazující na data tohoto druhého souboru, což mění další blok bitových map… Když vyřešíte problém sledování specifických závislostí jakéhokoliv konkrétního zápisu, skončíte se složitostí měkkých aktualizací. Nepřekvapí tedy, že většina souborových systémů používá přístup hrubou silou, což vede k tomu, že fsync() obvykle zabere čas odpovídající všem zápisům do souborového systému.
Nyní tedy máme následující situaci: Abychom mohli garantovat, že jsou data souboru na fyzickém úložišti, potřebujeme fsync(), ale to se může chovat libovolně špatně podle toho, jaká další aktivita v souborovém systému probíhá. Vzhledem k tomu vývojáři aplikací začali spoléhat na to, co je na první pohled naprosto rozumný předpoklad: rename() jednoho souboru přes jiný soubor vyústí buď v to, že daný soubor bude obsahovat stará data, nebo nová data z doby, kdy bylo rename() voláno. To je jemná a zajímavá optimalizace: Místo toho, aby byl souborový systém požádán, aby synchronně zapsal data, je žádán, aby zápisy řadil. Řazení zápisů efektivně je pro souborový systém mnohem jednodušší, než efektivně provádět synchronní zápisy.
Řadící efekt rename() je nicméně pouze vedlejší jev specifický pro implementaci souborového systému. Funguje pouze v případě, že jsou změny dat souboru v souborovém systému řazeny s ohledem na změny metadat souborového systému. V ext3/4 je toto pravda jenom v případě, že je souborový systém připojen s volbou data=ordered – což je jméno, které teď snad dává větší smysl. Donedávna byl výchozí režim žurnálování ext3 v Linuxu data=ordered a ext3 zase byl výchozí souborový systém pro Linux; výsledkem je, že režim data=ordered v ext3 byl to, s čím mělo nejvíc vývojářů aplikací pro Linux zkušenosti. Během Velkého převratu souborových systémů v 2.6.30 se ale výchozí režim žurnálování v ext3 změnil na data=writeback, což znamená, že data souboru jsou zapsána na disk, až když se souborovému systému zachce, velmi pravděpodobně až poté, co se zapíší metadata tohoto souboru specifikující, kde je jeho obsah na disku uložen. To nejenom narušuje předpoklad o řazení rename(), ale také to znamená, že nově přejmenovaný soubor může obsahovat libovolný bordel – nebo kopii /etc/shadow, což znamená bezpečnostní díru stejně jako problém s poškozením dat.
Což nás přivádí zpět do současné rozepře fsync()/rename()/O_PONÍCI, ve které mnoho vývojářů souborových systémů tvrdí, že aplikace by měla explicitně volat fsync(), předtím než přejmenuje soubor, pokud chce, aby data souboru byla na disku, předtím než dojde k přejmenování – postoj, který se zdá být bizarní a náhodný, dokud nepochopíte jednotlivá rozhodnutí, která jsou všechna naprosto rozumná a která se skládají do současné situace. Osobně si jako vývojář souborového systému myslím, že je kontraproduktivní nahradit pro výkonnost přátelský požadavek na implicitní řazení v podobě rename() neoptimalizovatelným fsync(). Nemusí to být POSIXové, ale záměr programátora je jasný – nikdo nikdy nenapsal creat(); write(); close(); rename(); s touhou, aby dostal prázdný soubor, pokud systém během následujících pěti minut spadne. K tomu slouží truncate(). Zobecněný příznak „O_PONÍCI, dělejte to, co potřebuji“ jistě není možný, ale v tomto případě si vývojáři souborových systémů sami pomohou, když rozšíří sémantiku rename() tak, aby implikovala řazení, a tím omezí počet volání fsync(), se kterými se musí potýkat. (A, což zde musím poznamenat, jako malá jsem měla opravdového živého poníka, takže mám tendence být na té straně, která by dávala programátorům poníky, když si o ně řeknou.)
Můj názor je, že POSIX a většina dalších užitečných standardů slouží jako užitečné objasnění existujících praktik, ale není dostačující, když narazíme na nové překvapující okolnosti. Kritizujeme vývojáře aplikací za to, že používají folklórní programátorské techniky („Zdá se, že to funguje!“) a spoléhají přitom na vedlejší jevy specifické pro souborové systém, ale čisté specifikace POSIX zjevně nedostatečně definují užitečné chování systému. V případech, kdy je záměr programátora nejasný, bychom měli udělat správnou věc a nové chování přidat na seznam pro další jednání o standardech.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
2.10.2009 10:46
Algi | skóre: 1
| blog: Sinner
2.10.2009 11:04
AraxoN | skóre: 47
| blog: slon_v_porcelane
| Košice
větší hanba by měla fackovat redaktory ABCLinuxu za používání slova O_PONÍCIPročpak?
+1
a navíc - jako autor překladu na to máte licenci :)
2.10.2009 19:14
Jakub Lucký | skóre: 40
| Praha
hardware Android (staging/andriod)
budete se vám to líbit!“
Nemusí to být POSIXové, ale záměr programátora je jasný – nikdo nikdy nenapsal creat(); write(); close(); rename(); s touhou, aby dostal prázdný soubor, pokud systém během následujících pěti minut spadne.Totéž, co u minulých JN - pokud někdo dělá hovadiny, kvůli kterým mu padá počítač, ať si nechá opatchovat jádro. Nevidím důvod, proč by měli ti, kteří provozují stabilní systém (ať už server nebo desktop), mít v jádře nějaké dobastlené opatření pro případ, kdy systém spadne, když se to prostě nestává.
Vyhoďte UPSky, zapomeňte na defenzivní programování a hail zaslepenost!Není nad překrucování, že? Nikdo neříká, že souborový systémů může svévolně ztrácet data, nicméně ztráta dat způsobená tím, že spadl systém, není vina souborového systému. A pokud se to někomu nelíbí, ať kvůli tomu nesviní jádro bordelem všem ostatním. Jestliže se jeden kus kódu v jádře rozhodne, že soubor x na disku nebude v určité podobě existovat dost dlouho na to, aby se ho vyplatilo zapisovat, proč je tam jiný kus kódu, který řekne, že ho přece jenom zapíšeme? A poznámka o UPS je úplně mimo. Jednak výpadek napájení zpravidla nelze ovlivnit (narozdíl od výběru hardwaru a softwaru), druhak připojení UPS nezpůsobuje výkonnostní postihy narozdíl od kódu pro speciální případy typu "hustovole přetaktoval jsem grafárnu, pak mi to spadlo a chyběly mi data".
2.10.2009 07:37