Byly vyhlášeny výsledky (YouTube) 28. ročníku D.I.C.E. (Design, Innovate, Communicate, Entertain) Awards: Hrou roku 2024 je Astro Bot.
Všem na AbcLinuxu vše nejlepší k Valentýnu aneb Dni lásky ke svobodnému softwaru (I love Free Software Day, Mastodon, 𝕏).
Vývojáři openSUSE Tumbleweed oznámili, že u nových instalací se ve výchozím stavu přechází z AppArmor na SELinux. Uživatelé, kteří chtějí zůstat na AppArmor si mohou AppArmor vybrat v instalátoru.
Hector "marcan" Martin skončil jako vedoucí projektu Asahi Linux aneb Linux na Apple Siliconu. Projekt ale pokračuje dál.
PostgreSQL byl vydán ve verzích 17.3, 16.7, 15.11, 14.16 a 13.19. Řešena je zranitelnost CVE-2025-1094 s CVSS 8.1 a více než 70 chyb.
Dnes je Světový den rádia. Použili jste někdy GNU Radio?
Před 33 lety, ve čtvrtek 13. února 1992, se tehdejší Česká a Slovenská Federativní Republika oficiálně (a slavnostně) připojila k Internetu.
Byla vydána nová verze 9.10 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání.
Český LibreOffice tým vydává překlad příručky LibreOffice Math 24.8. Math je modul editoru vzorců v kancelářském balíku LibreOffice a poskytuje možnosti rozvržení pro zobrazení matematických, chemických, elektrických nebo vědeckých vzorců ve standardní písemné notaci. Příručka je ke stažení na stránce dokumentace.
Společnost Backblaze zveřejnila statistiky spolehlivosti pevných disků používaných ve svých datových centrech za rok 2024. Ke konci roku 2024 vlastnila 305 180 pevných disků. Průměrná AFR (Annualized Failure Rate), tj. pravděpodobnost, že disk během roku selže, byla 1,57 %. V roce 2023 to bylo 1,70 %. V roce 2022 to bylo 1,37 %.
Uplynulo už desať rokov od chvíle, čo som naposledy vyberal súborový systém. Vtedy zvíťazil ext4, ktorý som odvtedy spokojne používal. Množia sa ale v diskusiách tu aj inde pohrdlivé komentáre na túto konzervatívnu voľbu.
Namiesto prehlbovania hádok, kde si každý bude trvať na svojom, rozhodol som sa podrobiť súčasný stav testovaniu a potom výsledky zverejniť. Plne očakávam, že tým započnem novú hádku, kde si každý bude naďalej trvať na svojom. Ale nepredbiehajme.
Pre niekoho môže byť prekvapením, že súborové systémy si navzájom nie sú rovné a v niektorých čiastkových parametroch sa môžu líšiť až rozdielom dvoch rádov. To čo jeden zvládne za prijateľnú minútku, inému môže trvať viac než hodinu. Väčšina používateľov ale výberu súborového systému nevenuje vôbec žiadnu pozornosť, aj keď sa jedná o vec, ktorá by jeho user experience mohla zlepšiť až rádovo.
Na testovanie som si z firemného vrakoviska požičal HP ProLiant MicroServer Gen8, vložil do neho 2 disky pre systém a archív s testovacími dátami, a ďalšie 2 disky pre samotné testovanie súborových systémov.
Ako operačný systém poslúžilo Gentoo, v ktorom bolo nainštalované len nutné minimum. Každý súborový systém som testoval v troch fázach.
V prvej fáze som súborový systém zaplnil dátami zhruba na 80% a v tejto testovacej populácii skúšal základné operácie, ktoré ako administrátor občas robím - zisťoval obsadené miesto v adresároch (príkaz du
), hľadal súbory cez find
, kontroloval súborový systém cez fsck
a potom časť dát (asi štvrtinu) mazal (rm
).
V druhej fáze som súborové systémy postupne podrobil štandardizovaným benchmarkom iozone
, bonnie
a dbench
.
V tretej fáze som simuloval bit rot a sledoval, ako sa to prejaví na dátach.
Medzi jednotlivými testami som súborový systém vždy odpojil (umount
) a potom znova pripojil (mount
), čím sa efektívne vyprázdnili cache a buffery k nemu sa viažuce.
Ďalšie technické detaily sú nižšie v článku, ale teraz už poďme k tabuľke s výsledkami, než Vás unudím na smrť.
Jednotlivé čiastkové testy sú na vodorovnej osi a zoradené sú v poradí, v akom boli postupne vykonávané.
Súborové systémy sú v riadkoch tabuľky a zoradené sú v poradí, v akom ich zobrazuje make menuconfig
pri zostavovaní linuxového jadra.
Zvýraznené sú najlepšie a najhoršie hodnoty v rámci daného testu, ako aj to, či súborový systém v teste skončil v lepšej polovici, alebo v horšej (t.j. či je výsledok nad mediánom, alebo pod ním). Výnimkou je test bit rot, tam som presvedčený, že akýkoľvek výsledok iný než nula je nedostatočný a rôzne počty poškodených súborov sú len vecou náhody.
Ak k jednotlivým testom priradíme subjektívne váhy a rozdáme body, poradie môže vyzerať takto:
Obe výsledkové tabuľky si môžete stiahnuť tu (formát LibreOffice Calc) a zadefinovať si svoje vlastné váhy, aby ste si našli súborový systém Vám na mieru (alebo aby ste dokázali ďalej obhajovať toho svojho favorita).
Ext2/ext3 je súborový systém, ktorý neurazí, ale ani nikoho neoslní. Mimo /boot oddielu sa dnes už asi príliš nevidí. Pre mňa je prekvapením, že ext3 je v mnohom rýchlejší, aj keď by sa od ext2 mal líšiť len prítomnosťou žurnálu. Jeden by si pomyslel, že pridané starosti so žurnálom výkon skôr zabrzdia. Možno sa mu od programátorov linuxového jadra dostáva viac optimalizácií.
Ext3 síce obhájil tretie miesto, ale mladší konkurenti mu už dýchajú na päty.
Súborový systém ext4 zostáva naďalej dobrou konzervatívnou voľbou, ktorá sa vo všetkých testovaných parametroch ako jediná udržala v hornej polovici. Áno, chýbajú mu checksumy a podpora pre viac diskov, ale možno práve vďaka svojej jednoduchosti môže excelovať v ostatných parametroch.
V teste si zaslúžene vysúťažil druhé miesto.
Časy súborového systému od Reisera sú asi nenávratne preč. Verzia 4 zmizla z aktuálneho jadra, zostáva len verzia 3, pravdepodobne z legacy dôvodov, rovnako ako ext2/ext3, či jfs.
Ťažko hľadám nejaké pozitíva jfs. Najdlhšie mu trvalo, kým sa na neho skopírovali dáta, najdlhšie mu trvalo, kým sa z neho zmazali. V syntetických benchmarkoch prevažne pohorel. Možno má nejaké špecifické žiadané vlastnosti, ale výkon k nim rozhodne nepatrí.
Xfs bol jediný súborový systém, ktorý konzistentne dokázal zamrznúť v iowait krátko po začiatku prvého kroku (kopírovanie dát). V použitom linuxovom jadre 5.15.32-r1 podľa všetkého je nejaká zašmodrchaná chyba, pretože s jadrom 4.9.309-r1 sa odrazu všetko plynulo rozbehlo. Keď som hľadal, či niekto takúto chybu do jadra nehlásil, našiel som celý rad ďalších bugov, ktoré rozhodne nemaľovali obrázok stabilného súborového systému.
Dodatok z dňa 26.5.2022: chyba bola oznámená do kernel bugzilly a v krátkej dobe opravená. Do tej miery, akej tomu som schopný porozumieť, v skutočnosti nešlo o chybu xfs, ale o to, že API jadra sa chovalo trochu inak, než očakával volajúci (xfs).
Nilfs2 je súborový systém, ktorý najlepšie znášal záťaž generovanú benchmarkom dbench
(mnoho súbežne bežiacich požiadaviek). V ostatných parametroch nebol žiadnou hviezdou, napriek tomu už teraz chystám jeho test v súvislosti s databázou PostgreSQL.
Napriek tomu, že je určený pre iný typ záznamového média (flash karty), f2fs si na rotačných diskoch viedol prekvapivo dobre. V benchmarku bonnie
uhral dokonca prvé miesto. Keby som robil s Raspi, nad f2fs by som rozhodne aspoň uvažoval.
Vyzývateľ s ťažko vysloviteľným názvom už v minulosti robil veľké vlny. Doteraz som bol presvedčený, že jeho checksumy a zložitosť musia zákonite znamenať mizerný výkon. Opak je ale pravdou, btrfs zvíťazil v najväčšom počte testov. Nejaké slabšie stránky oproti ext4 stále má, ale už sa nedivím, že je miláčikom nezanedbateľnej časti publika. Asi sa jeho fanúšikom pomaly stanem aj ja.
Rozhodne zaujímavo vyzerajú jeho samoopravné schopnosti, ako aj výborné výsledky v benchmarku dbench
. V tých len málo zaostával za nilfs2. Takže aj ja sám, ešte pred týždňom skeptik, sa chystám btrfs naštudovať viac do hĺbky, aby som ho v dohľadnej dobe mohol nasadiť do ostrej prevádzky.
Btrfs sa neodškriepiteľne a s dostatočným predstihom stáva víťazom testu.
Zfs som pôvodne ani nechcel do testu dávať, pretože v linuxovom jadre sa jeho ovládač nenachádza. Napriek tomu som to spravil, len aby som si potvrdil všetky negatívne stereotypy, ktoré som mylne pripisoval btrfs. Zfs je zbytočne komplikovaný, je pomalý a mrhá priestorom na disku. Jeho jedinou svetlou stránkou je schopnosť ustáť bit rot.
Potom, čo sa zfs a btrfs dostali pod tú istú firmu, predpokladám a dúfam, že sa vývoj sústredí skôr na ten druhý, ktorý má rozhodne nádejnejšiu budúcnosť.
Na ceste je nový databázový server, ktorý budeme nasadzovať v lete. Rád by som aj na ňom zbehol podobné testy, tentoraz na SSD diskoch a s dôrazom na výkon PostgreSQL (v14.2). Nejaké nápady, ako benchmarkovať PostgreSQL?
To je k výsledkom testu všetko, nasledujú nezaujímavé technické detaily:
Primárnym cieľom bolo vytvoriť dostatočne veľkú populáciu testovacích dát. Sekundárnym cieľom bolo simulovať rýchlosť, akou je možné migrovať staré dáta na nový disk.
Zdrojom testovacích dát bol nekomprimovaný archív na systémovom disku. Odtiaľ sa rozbalili na testovací disk (resp. testovacie diskové pole RAID1). Testovacie dáta pozostávali z 2,6-milióna súborov v 1024 adresároch, spolu 758,5GB dát.
Výsledok testu je vyjadrený časom v minútach. Menej minút je lepší výsledok.
Cieľom bolo odmerať efektivitu uloženia rovnakej množiny údajov na rôznych súborových systémoch.
Výsledok testu je vyjadrený v gigabajtoch. Menej GB je lepší výsledok.
Cieľom bolo zistiť, ako rýchlo je možné spočítať, koľko miesta zaberá niektorý z adresárov testovacej populácie.
Výsledok testu je vyjadrený časom v sekundách. Menej sekúnd je lepší výsledok.
Cieľom bolo zistiť, ako rýchlo je možné v testovacej populácii nájsť súbory, ktoré vyhovujú zadanej podmienke.
Výsledok testu je vyjadrený časom v sekundách. Menej sekúnd je lepší výsledok.
Cieľom bolo odmerať, ako dlho trvá operácia fsck
spustená preventívne (t.j. ak sa neočakáva, že by súborový systém mal byť poškodený). Fsck bol spúšťaný s parametrami force
a read-only
, resp. no
tam, kde to bolo možné.
Výsledok testu je vyjadrený časom v sekundách. Menej sekúnd je lepší výsledok.
Cieľom bolo zistiť, ako rýchlo je v danom súborovom systéme možné vymazať veľké množstvo súborov. Nejednalo sa o mazanie za účelom nenávratnej skartácie (napr. shred), ale len o odstránenie súborov a uvoľnenie miesta, ktoré zaberali, pre iné využitie.
Výsledok testu je vyjadrený časom v sekundách. Menej sekúnd je lepší výsledok.
Cieľom bolo zistiť rýchlosť behu benchmarku iozone v plne automatickom móde. Ďalšie výstupy tohto benchmarku presahujú rámec tohto dokumentu a neboli predmetom testu.
Výsledok testu je vyjadrený časom v sekundách. Menej sekúnd je lepší výsledok.
Cieľom bolo zistiť rýchlosť behu benchmarku bonnie s parametrom -s 32768
(32 GB, číslo zvolené tak, aby bolo niekoľkonásobne vyššie než dostupná RAM).
Výsledok testu je vyjadrený časom v minútach. Menej minút je lepší výsledok.
Cieľom bolo zistiť hrubý výkon a spozdenie pri simulovanej záťaži tvorenej 64-mi súbežne bežiacimi procesmi benchmarku dbench.
Výsledok testu throughput je vyjadrený megabajtami za sekundu. Vyššie číslo znamená lepší výsledok.
Výsledok testu latency je vyjadrený časom v sekundách. Menej sekúnd je lepší výsledok.
Cieľom bolo zistiť, ako si poradí súborový systém v prípade, že na disku sú chybne uložené niektoré bity.
K tomuto účelu bolo náhodne zmenených 50 bitov na jednom disku a 50 iných bitov na druhom. V prípade linuxového SW RAID1 bol ten následne znova zostavený. Potom bol súborový systém opätovne pripojený.
Výsledok testu je vyjadrený počtom súborov, ktoré boli stratené, alebo bol ich obsah pozmenený (podľa ich dopredu známeho hashu). Menší počet stratených súborov predstavuje lepší výsledok.
HP ProLiant MicroServer Gen8 v konfigurácii:
Žiaden z diskov podľa môjho najlepšieho vedomia nebol so švindľovým zápisom (SMR).
Poznámka: * v prípade BTRFS a ZFS ich interný RAID1 z dvoch diskov, v ostatných prípadoch obyčajný linuxvý SW RAID1.
Ako operačný systém bola použitá čistá inštalácia Gentoo Linuxu s týmito verziami balíčkov (vymenované len tie, ktoré sú k testu relevantné):
Tiskni
Sdílej:
Rozhodne zaujímavo vyzerajú jeho samoopravné schopnostiNo ale jenom v případě poškození dat na disku. Chyby v RAM (pokud nemáš ECC, nebo ti softwarový bug něco poškodil) vedoucí na poškození struktur FS jsou pro změnu fatální na rozdíl od jiných FS, protože u btrfs je fsck experimentální a u ZFS není vůbec. To df used by bylo zajímavé dělat nějak podrobněji, protože nevím jestli jenom z used se dá vykoukat efektivita, může se třeba stát, že used+free < kapacita disku, ne? Takže ideálně tam potom zkusit zapisovat další data a koukat kolik jich tam doopravdy narvu. Ten výkon při obsazování si myslím že bude dost ovlivněn i zdrojem dat - mnohem lepší by bylo generovat je synteticky.
ext4 ... chýbajú mu checksumyDat. Checksumy metadat to má.
Vie nejak požiadať SW RAID1, aby mu vrátil rovnaký blok, ale z druhého disku?Tipnul bych si, že tohle rozhraní mezi filesystémem a blokovým zařízením momentálně neumí
umount
)mdadm --stop
)mdadm --assemble
)mount
)find /mnt/test -type f -print | sort | xargs md5sum > /tmp/hash.txt
)diff
)fsck
. Btrfs a zfs dokázali chybu nájsť a transparentne opraviť. Používateľ btrfs sa to dozvie iba zo syslogu, zfs o tom neinformuje vôbec.
zfs o tom neinformuje vôbecUž to vyhodili z výstupu príkazu
zpool status
? Vídaval som tam pri podobných testoch.
ZFS má SCRUB, ten skontroluje konzistenciu zapísaných dát podobne ako FSCK u iných FS.Ne, zkontroluje pouze checksumy.
To je zaujímavé... tá štruktúra sa Ti kazí na btrfs?Ano.
Pri akej príležitosti? Strata napájania?Nevím, protože to nemá fsck co by člověk mohl pouštět po každém bootu, tak na to nepřijdu až dokud nenastane nějaký problém typu „nejde spustit postgresql“ nebo „rsync při zálohování nemůže přepsat soubor“. Napájení se ztrácí pravidelně (řešil jsem v poradně, ptal jsem se všude, stále bez úspěchu), RAM není ECC a softwarový stack je pochybný (nvidia blob + deep learning bastly v dockerech).
Tie checksumy overia či bloky (obsahujúce hoci aj dátovú štruktúru) neboli poškodené.Jak si představuješ, že to opraví následující chybu:
Máme novej PALM, podle paperu to vypadá nadějně, tak to otestujeme.Tak ho implementuj ako modul do súborového systému, keď si sa s tým pochválil v diskusii o súborových systémoch.
Jak si představuješ, že to opraví následující chybu: (bitflip, ...)Nijak. To neopraví ani FSCK, len to zabrúsi za cenu straty užívateľských dát. To opraví akurát tak ECC na špeciálnom HW s redundantným vykonávaním kódu a porovnávaním výsledkov. Alebo obnova zo zálohy.
Nijak. To neopraví ani FSCK, len to zabrúsi za cenu straty užívateľských dát.Zabrúsi = dostane FS zase do konzistentního stavu, aniž bych musel dělat odstávku na vytvoření nového FS a přelití dat tam a zpátky. Navíc na ZFS, kde fsck není, se o tom, že se tohle stalo, ani nedozvíš. Data se při tom občas ztratí (tak jako tak), obnovíš je ze zálohy, nebo se jedná o nějaké dočasné soubory na kterých nesejde.
xfs_check
. Vlastne ani btrfs nemá fsck, ale btrfs check
, takže správne mal mať vo výsledku, že fsck "nemá".
Celý tento test nebol veľmi šťastný, pretože ak fsck trvá dlhšie, môže to znamenať, že je dôkladnejší a odhalí/opraví viac chýb. Preto som tomu nakoniec dal nulovú váhu.
Jinak jako vhodnou odpověď bych bral, že ntfs neni linuxový souborový systém a proto byl z testů vynechán. Tím by se to řešilo.
Je starý (k normálním lidem se dostal s dvoulitrama nebo xp na přelomu tisíciletí, ale ani tehdy nebyl nijak nový, roky předtím ho používaly nt), ale jestli je zastaralý to je otázka jiná (desítky jej stále používají jako základ). No při tom stáří by se zastaralost dala očekávat.
Arduino (AVR) a Raspberry jsou poslední dobou nedostupné (a co je dostupné stojí násobky cen, které pamatuju).Zajímavé je, že Číňan AVRka docela má (jak na Ali, tak LCSC/JLC). Nevím jestli padělky -- popis vypadá jinak, ale to taky může být způsobeno tím, že je koupil Microchip.
Super zápis, díky.
To jsem zvědavý na ten další test.
shared_buffers
na štvrtinu veľkosti RAM a pgbench
spúšťajú s parametrami:
pgbench -j $NUM_CPU_CORES -n -T 120 -r pgbench
Môžem sa tým inšpirovať.