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í/provedený bez kontextu. Originální commit message anglicky:
Many cleanups and bug fixes in ext4, especially for the fast commit feature. Also some performance improvements; in particular, improving IOPS and throughput on fast devices running Async Direct I/O by up to 20% by optimizing jbd2_transaction_committed().
kde předpokládám, že smysl druhé části je
Také může přinést výkonnostní zlepšení; specificky navýšení IOPS a propustnosti pro rychlá zařízení až od 20% při provádění přímých asynchronních vstupně/výstupních operací díky optimalizací v jbd2_transaction_committed().
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/enginy/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ý.
Nj, python je dobré lepidlo.
Ja som zvláštny prípad, používam raspberry pi 5 ako hlavný počítač z dôvodu, lebo môžem. A čakám na pokazenie SD-karty.
Proste len zo zvedavosti, či je to takým spôsobom použitelné. Sprvu mi strašne hučal vetrák, ale už sa to nejak napravilo. Neviem, či to bola sw, alebo hw záležitosť. Je to fajn počítač (zatiaľ), používam ho od vianoc. Najčastejšie sa bavím na komentároch - Nedokáže to X, má to málo výkonu. Len moje rpi asi o tom nevie. (Neberte to osobne prosím).
NXP sme používali v robote, písal som na to programy pre J9.
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).
Vy taky nectete changelogy u LTS kernelu? ;-) Treba tenhle commit nove featury do LTS 6.1 pridava...