Vlákno názorů ke zprávičce Ext4 bude v Linuxu 6.11 až o 20% rychlejší od Mmmartan - Tak to si musím někam poznamenat, že přechod...

Tak to si musím někam poznamenat, že přechod na nové jádro 6.11 budu co nejvíc odkládat, než se všechno pořádně otestuje

Mimochodom toto:

Na rychlých zařízeních využívajících Async Direct I/O

To sú aké zariadenia napríklad? Pomôže to aj povedzme sd-karte v mojom raspberry pi 5, alebo musím mať nejaké supermoderné diskové pole?

Předpokládám, že ne. Limit je SD karta, kdy se určitě nejedná o rychlé blokové zařízení. Na RPi5 by řádově více pomohlo použít PCIe linky pro připojení NVMe disku přes M.2 slot a to již do kategorie rychlých blokových zařízení možná může spadat na RPi a v poměru k výkonu CPU tam optimalizace na úrovni FS může možná přidat pro specifický scénář i více 20%.

Jenže si myslím, že překlad původní zprávy panem Ježkem je nejspíše silně zavádějící/pro­vedený bez kontextu. Originální commit message anglicky:

kde předpokládám, že smysl druhé části je

Takže se bude jednat velké o databázové aplikace a další seriózní a na výkon optimalizovaný SW, který k souborům přistupuje přes Direct I/O a to na několik míst naráz asynchronně. Aby to mělo smysl, jedná se většinou o přístupy po velkých blocích atd. Předpokládám, že zrychlení pak také může nastat i při direct I/O přes I/O uring atd... Ale pokud provozujete běžné aplikace nebo i desktop a třeba nějaké skriptování v Pythonu atd. tak tam vůbec nepředpokládám takovýto návrh interakce s operačním systémem.

Naopak opravy chyb asi hlavně v oblasti zotavení z nedokončených operací atd. mohou mít cenu. I když i dříve byl Ext4 překvapivě vůči chybám odolný. Sám i na SD karty dávám BTRFS, ale je hodně pravděpodobné že je to obrušuje a bude to pomalejší a systém s SD kartou jako hlavním úložištěm je pro každé mé seriózní nasazení NO GO. I do výuky, když se kity nepůjčují domů, řeším boot embedded GNU/Linux HW vždy přes NFS root a tmpfs overlay (diskless).

Ďakujem za vysvetlenie, napísali ste to aj pre blbcov (mňa). Konečne mám trochu jasno, aspoň budem môcť mudrovať v robote.

Len offtopic - Python ma vie niekedy prekvapiť rýchlosťou, ak sa používa určitým spôsobom. Totiž niektoré nadupané knižnice (frameworky/en­giny/whatever) napísané v C a Fortrane majú python len ako user friendly fasádu. Nepochybujem, že napríklad pán Tišnovský ich tu niekde rozoberá. Tak aj to Async Direct I/O sa môže niekde takto používať.

Tak sám mám Python jako skriptovací lepidlo a třeba i webový framework pro ne moc zatížený server rád. Třeba i na projekt https://eval.comparch.edu.cvut.cz/ jsem Flask jako jednu z voleb doporučil. Zde je něco o implementaci na InstallFestu - Webová evaluace úloh za použití Flask a QtRVSim. A ano, třeba NumPy v rychlosti maticového násobení při použití Atlasu nebo i dalších fast BLAS variant předčilo ručně laděné kódy semestrálek našich studentů v Pokročilých architekturách počítačů a to i pokud použili kombinaci MPI a OpenMP. Ale pokud bych stavěl web pro zátěž jako má Seznam, CSFD atd. tak bych do kritické cesty počítání a ani spojení knihoven nestavěl.

Spíš mám kritický postoj k tomu všude používat Rasberry Pi a neochotu se kouknout kamkoliv jinam, kde je i na ARMech je NVMe a nebo jiné slušné úložiště k dispozici. Rasberry Pi 1 až 3 určitě nepatří do aplikací, kde je potřeba buď spolehlivost úložiště nebo komunikace, Ethernet po USB je dobrý na systém na hraní, získávání zkušeností, ale jinam ne. RPi4 zase má garantovanou frekvenci 0 MHz při překročení teploty pouzdra 85 °C. To. že jsou firmy, které nad těmito deskami staví PLC a garantují je jako plně funkční do teploty okolí 85 °C a třeba v Německu je používají snad na všech čerpacích stojanech s kapalným vodíkem, považuji za diletantismus. Když SoC od Texas Instruments (lze vybrat varianty AM3352, AM6x, DRA7x, AM57x s rozsahem -40°C až 125°C), NXP (opět lze vybrat varianty iMX6,8,9 s rozsahem -40°C až 125°C) atd.. mají spolehlivost i teplotní rozsahy zcela jinde.

I u Vás, pokud chcete trochu propustnost a spolehlivost, tak doporučuji rozšíření obzorů. I když uznávám, že RPi5 má výkon i v porovnání s těmi Ti a NXP slušný. Ale stejně bych mu moc nevěřil a s SD kartou na trvalý provoz i s jen základními požadavky na spolehlivost již vůbec ne. S NVMe by to mělo být trochu lepší, ale stále ten SoC považuji za vhodný spíše na hraní nebo do nekritických multimediálních zařízení, kam byl původní RPi1 Broadcom SoC učený.

To ale pak pozorne ctete changelogy i k LTS kernelum. Protoze samozrejme to, ze se to tam muze backportnout tam se casem prihodit muze - a spis to se obcas uplne nepovede (pred dvema roky jsem takto na neco narazil v 5.15 - kdy se sice kod zkompiloval skvele, takze testy, co obvykle delaji v kernelu to proslo... jen postizeny hardware jaksi nefungoval).

nie je podstata LTS v backportovani bugfixov a ignorovani novych features?

Vy taky nectete changelogy u LTS kernelu? ;-) Treba tenhle commit nove featury do LTS 6.1 pridava...