Názory k článku
Debian má chybu v jádře a rozbíjí ext4, zatím neaktualizujte

Díky, teda to bylo u mě na poslední chvíli... Pustil jsem apt update+upgrade a než to doběhlo, využil jsem čas, otevřel si Root.cz a no ty kráso. Ale vypadá to, že teda zatím zablokobané nové balíky nejsou - base-files se mi před pár minutami zvedly na 12.3 a ten špatný kernel (6.1.64-1, tedy balík linux-image-6.1.0-14) tam mám už taky, naštěstí ho mám možnost máznout ještě před rebootem, který by proběhl už do něj. Ufff.

Huh, to se nám ty backporty do stable nějak kazí. Nejdřív sériáky, teď tohle… Asi bude potřeba udělat nějaké "stable stable", protože ze stable se stal testing :-)

No me prijde, ze ti kernelovi vyvojari se nekdy snad ani neobtezuji ty backporty otestovat. Ke stesti jim staci, ze se to zkompiluje - nejake testovani (nedejboze na hardware, ktereho se to explicitne tyka) se moc neresi a obcas se pri tom vyzobavani rozinek do LTS verzi i zapomene na nejake souvisejici upravy.

A GKH na jedne strane rika, jak maj lidi pouzivat aktualni verze. Ale ta 6.1.64 byla v nejakem case aktualni - a dokonce krasnych 10 dni, kdy neotestovani zmen v long-term stable, kdy s jeho logikou ohrozoval data lidi. Mozna by to chtelo fakt pribrzdit na kvantite co se mnozstvi zmenovych commitu tyce...

No me prijde, ze ti kernelovi vyvojari se nekdy snad ani neobtezuji ty backporty otestovat.

Je to ještě mnohem horší. Doby, kdy vývojáři příslušného subsystému explicitně označovali, co se má backportovat do stable, jsou dávno pryč. Dnes tomu vládnou skripty, které automaticky vezmou všechno, co má Fixes:, a na základě nějakých podivných heuristik i hromadu dalších věcí. Dnes je spíš problém, jak zabránit tomu, aby se commit, o němž se předem ví, že by backport mohl způsobit problémy, do stable stejně dostal.

A pak se vsichni strasne divej, proc ti co to adminujou radsi pouzivaji i roky starou verzi, protoze proste nechteji resit co kde prestane fungovat, coz je pro ne mnohem vetsi problem, nez z 99% hypoteticky vyuzitelne chyby.

Osobne cekam s jakoukoli aktualizaci alespon 3-4 dny (u tech nepodstatnych veci) a u tech kritickych nejmene mesic. Ale ani to nemusi vzdy stacit.

Tohle není žádný backport do stable. To je stabilní kernel z kernel.org, který bohužel měl v konkrétním vydání chybu.

To teprve teď bude muset Debian buď udělat backport opravy chyby do svého stable a nebo bude muset použít novější vanilla kernel bez chyby.

Já myslel, že to Debian backportoval do svého balíku?

Nikoliv, tohle vzniklo primo v upstreamu - tedy v ramci divokeho backportovani zmen z novejsich verzi do LTS kernelu. Debian tu chybu jen prevzal.

Aha, díky za vysvětlení.

Jestli tomu rozumím správně, tak je to opravené až v jádru 6.5-rc1, takže když mám v Linux Mintu jádro 6.2, tak se mě to také týká, cituji:

"The commit got merged in 6.5-rc1 so all stable kernels that have
91562895f803 ("ext4: properly sync file size update after O_SYNC direct
IO") before 6.5 are corrupting data"

Ale to tvoje 6.2 nejspíš nemá to 91562895f803, ne?

6.2 je uz od kvetna EOL, 6.5-rc1 je nekdy z cervence.

V te 6.5 jsou dva commity - 91562895f803 (ext4), 936e114a245b6 (iomap) - ale backportoval se do 6.1.64 jen ten prvni - proto ten prusvih. Ten druhy patch dolepili az v 6.1.66.

Takže chápu to dobře, že chyba se objevila jen v jádrech 6.1.x, které backportovaly patch na chybu opravenou v 6.5, ale v té 6.5 se korupce dat nevyskytuje (jelikož se udělala oprava správně)? Stejně tak ani v >6.1 & <6.5 (protože neexistoval patch, který by ji vyvolal)?

Realne je postizena jen 6.1... v 5.15 a starsich LTS se pred 12 dny ten problematicky commit k ext4 vubec neobjevil, stejne tak to nikdo necpal do stabilnich 6.2 az 6.4 (ale ty "stabilni" ne-LTS verze maji jepici zivot obecne). Ten druhy iomap pristal pred 2 dny jeste v 5.15, do starsich uz nesel.

Jestli jsem to pochopil správně z tohoto článku, tak by to mělo být už vyřešeno. Může to někdo potvrdit?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057843

V bugu je skutečně napsáno, že to je opraveno v balíčku jádra verze 6.1.66-1. Ovšem v repozitářích je pořád ještě chybná stará verze 6.1.64-1. Zatím ještě vydržte.

# apt update
# apt show linux-image-amd64 | grep -E 'Version|Depends'

Version: 6.1.64-1
Depends: linux-image-6.1.0-14-amd64 (= 6.1.64-1)

Protože holt Debianu chvíli trvá, než oprava probublá až do stable. Nicméně se pořád dají použít debianí kernely, které chybu nemají.

Uz je na ceste.... (takze odvaznejsi uz muzou nasazovat)

https://tracker.debian.org/news/1484449/accepted-linux-signed-amd64-61661-source-into-proposed-updates/

A uz je to venku ;-)

debian bookworm InRelease' changed its 'Version' value from '12.3' to '12.4'
... linux-image-6.1.0-15-amd64 je ta vytouzena 6.1.66... :-)

A práve preto mám na produkčných serveroch overenú klasiku - JFS/XFS...

jasne, se XFS se to stat nemuze... :-)

To som nepostrehol, ale JFS je i tak na vacsine mojich serverov :)

Chyba se může stát všude, nedávno mělo třeba OpenZFS fatální chybu, která mazala obsah souborů. Nelze ukázat prstem na jeden souborový systém.

Pomaly ale isto mi to pride ako zlate MS NTFS, ten mi este nedomrvil ziadny disk. Nema to sice miliardu fancy featuriek, ale funguje.

Tak jednoduché to bohužel není, i v NTFS jsou chyby ničící data. Chyby se prostě stávají všude.

Preto každý normálny človek má zálohy. Zálohovanie je základný princíp ochrany dát pred stratou.

NTFS rozhodně nemá nulové skóre. Kromě data corruption bugu z jara 2021 bylo pekelné období nástupu Windows 2000, kde se objevila nová verze NTFS 5 a starší verze Windows NT 4.0 s ní po aktualizaci ntfs.sys uměla taky pracovat, ale prakticky ignorovala žurnál. Výsledkem byl v lepším případě dirty FS (vždy), no a když měl člověk smůlu, nakopnula se metadata. Podle MS to bylo chování by design, dokonce to měli v prezentaci na W2K deployment konferenci v prosinci 1998.

Problem neni v tom, ze nastane chyba, problem je v tom, ze takovahle chyba probubla do stabilnich verzi a prostrednicvim dister az k uzivatelum.

To neni ani na hlasku "mliko po brade". Pan si jeste nepamatuje kdy chcipnout XFS bez radneho odpojeni znamenalo dost slozite recovery.?

Když používám BTRFS, tak jsem v pohodě, že? Doufám :)

Ano, tato konkrétní chyba se týká jen ext4.

A to jsem si to dlouho rozmýšlel, jestli mi stojí za to ta opičárna se zprovozňováním btrfs na dualbootové mašině...

10. 12. 2023, 11:58 editováno autorem komentáře

Jo, BTRFS je proslulé neničením dat. /s

Proto jsem tak dlouho váhal. ;o)

Jenom taková úvaha. Zajímalo by mě, jaký je přínos změn, které způsobují tyto i jiné chyby. Nepamatuji si jedinou chybu, u které bych si říkal: "ok, změna byla velmi přínosná a chyby se prostě stávají". Naopak si pamatuju spoustu chyb, které vznikly na základě toho, že autoři chtěli řešit něco, co jsem za chybu buď nepovažoval a nebo měla být vyřešena na zcela jiné vrstvě nebo produktu. Například známá heuristika u ext4, která měla zjišťovat, zda program nezneužívá vlastnost journálování u ext3. Tam se prostě měly opravit všechny špatně napsané programy a nemělo se to zakrývat.

Jake vlastnosti zurnalu a jake zneuzivani? Odkaz prosim.. na problem i reseni

Odkaz nemám, probíralo se to hodně i tady na rootu. Šlo o to, že defaultní režim journálování u ext3 byl ordered. Což znamenalo, že data souboru se uložila před změnou metadat. Současně u ext3 byl velmi pomalý fdatasync. A některé programy tohoto zneužívaly, uložily data do soubory a následně jej třeba přejmenovaly. A data byla bezpečně na disku bez nutnosti volat f(data)sync.

Jenže tohle řešení fungovalo pouze na ext3 s ordered módem. Nefungovalo na žádném jiném fs.

Ext4 k sobě přidal heuristiku, jak tohle zachovat. Opět, nic to neopravovalo a na ostatních fs ten program byl stále rozbitý.

Nejedná se tedy o chyby ext3 ani ext4. Jen byla snaha najít náplast na vadné programy. A tohle mi vadí.

Jenze takhle se aplikace delaji vis?

Mockrat sem zazil, ze dodavatel se pokusil opravit nejake treba i objektivne vadne chovani. Jenze to vzdy narazi na to, ze aplikace s tim chovanim pocitaji.

Jedina spravna varianta je totiz tak, ze udelas novou verzi, ktere treba prejmenujes prislusna volani nebo pozadujes uvedeni verze ... a pak nove aplikace budou pouzivat tu opravenou funkcnost. Ale stejne budes muset nejspis desitky let zachovat i tu puvodni.

Specielne u FS pak menit jeho chovani je naprosto dokonala cesta do pekel. Pak totiz jaksi nemuzes tvrdit, ze je kompatabilni, protoze proste neni.

Ono je to docela problem, "tam se prostě měly opravit všechny špatně napsané programy".

Totiz ono ked sa aj vsetky programy opravia, vzdy sa najde nejaky vykuk, ktory pouzije staru verziu a problem aj tak sposobi. Koniec koncov distribucie ako Debian a RHEL spolu s klonmi na tomto priamo stavaju.

Preto kazda oprava, ktora zavadza nove spravanie, musi osetrit aj stare spravanie. Ako dlho musi podporovat stare spravanie je potom vecou zistovania, ci to este niekto niekde nahodou nepouziva, a az ked nie, este sa pre istotru s tym par rokov pocka a az potom sup s tym prec (a potom citaj na roote diskusie, ze preco sa odstranuju drivery pre historicke zelezo, ved to nikomu nezavadza, apod).

To je aj dovod, preco niektore zmeny vo svete Linuxu trvaju tak ukrutne pomaly. Microsoft alebo Apple si jednoducho vydaju novy release, kde spolu vsetky komponenty navzahom hraju; nikto nebude brat jeden komponent zo stareho releasu, druhy z noveho, robit z toho distribuciu a cudovat sa, ze to nefunguje. Vo svete linuxovych distribucii je to uplne bezne (preto dodnes nemame napr. explicit sync pre gpu).

Preto kazda oprava, ktora zavadza nove spravanie, musi osetrit aj stare spravanie.

Z ext3 nic nezmizelo. Takže kdo chtěl, mohl dál používat ext3 s ordered módem.

Jenze to bys tem lidem nemoh tvrdit, ze ext4 je nahradou za ext3, protoze neni.

Existuje nějaký podobný příklad v jiných OS? Třeba ve windows, že by automatická aktualizace takhle lowlevel krutě rozmasakrovala filesystém?

áno... a Petr Krčmář to tu aj psal... takýchto prípadov vo Windows je dokonca omnoho viac než v Linuxe... toto je v Linuxe skôr výnimka než pravidlo ako u MS... ale inak chyby sa stávajú všade... preto bleeding--edge (krvávajúce hranové) distrá nie sú vhodné stroje, kde je stabilita a spoľahlivosť dôležitá. Navyše vždy by si mal mať zálohu dát.

Az nato ze debian stable rozhodně neni bleeding edge...

10. 12. 2023, 15:02 editováno autorem komentáře

Debian neni bleeding-edge, ale tady je na vine upstream, ktery se o bleeding-edge v LTS kernelu misty snazi. Debian je pouze obeti toho divokeho pojeti na urovni samotneho kernelu - kdy se nektere zmeny backportuji tak nejak... neuplne.

Ako celok možno nie... ale ak sú prvý ku ktorým sa dostane commit vytvorený len pár dní pred ich "update", tak minimálne určitá časť u nich bleeding edge je. Inak by takýto problém ani nemali.

Tak z praxe mnohaletého provozu win a liunux vedle sebe můžu s jistotou říct, že počet podobných chyb v linuxu neznám, protože to už nepočítám a počet podobných chyb ve windows byl nula.

co treba:
Microsoft zastavil aktualizaci Windows 10 mazající uživatelská data
sice neslo o chybu filesystemu, ale aktualizacniho procesu, ale zaroven neslo o chybu "mohlo by se zapsat neco spatne", ale "realne se data mazala" ;-)

Navyše vždy by si mal mať zálohu dát.

Záloha ne vždy pomůže. Třeba u toho ZFS je to pěkný náběh na silent data corruption a tam by bylo vhodné kontrolovat hash těch dat. Ještě před umístěním na ZFS. Jinak se ti může stát, že poctivě zálohuješ data, která jsou třeba několik let už vadná.

Preto sa aj záloha má pravidelne kontrolovať... či dáta nechýbajú a či sú čitateľné a správne... Ak pol roka zálohuješ chybné dáta bez toho aby si si to všimol, robíš niečo špatne

U zálohy ani nejde o to zabezpečiť "100%" bez-stratu dát... to ani nejde. Ale ide o to minimalizovať škody, napríklad tak že keď príde k problému na primárnej stanici obsahujúce dáta, tak vieš obnoviť všetky dáta okrem tých ktoré sa ešte nezálohovali. To môže byť trebárs len dáta za posledný deň. O nejaké dáta prídeš, ale rozhodne je lepšie prísť o 3 fotky a 1 dokument, čo si uložil 10 minút pred poruchou, než aby si prišiel o všetky dáta od počiatku vekov. Ak zálohy pravidelne kontroluješ, a pravidelne zálohuješ, tým minimalizuješ škody. Čím častejšie, tým menej škody pri probléme.

10. 12. 2023, 17:07 editováno autorem komentáře

"Preto sa aj záloha má pravidelne kontrolovať... či dáta nechýbajú a či sú čitateľné a správne"

Takze jen potvrzujes, ze netusis o cem pises. Ty chyby byly o tom, ze na disku jsou z pohledu FS zcela spravna data, jak je chces kontrolovat? Ty budes kazdy doc/xls/txt ... rucne otevirat a zjistovat, jestli to uvnitr je citelne?

Vis jak dlouho muze trvat obnovovani dat? U mych ovecek se bavime v nejlepsim pripade o hodinach. V nekterych pripadech o desitkach dnu. Tudiz je to az to posledni co chces delat.

Zadna porucha neni, zadnou nezaznamenas, typicky se ti za 2-3 mesice nekdo ozve, ze mu soubor XYZ nejde otevrit, a ty pak mozna zjistis, ze takovych mas par mililonu.

Ve Windows jich taky pár bylo.. Já si pamatuji dva případy: jednou to rozbíjelo systém při náhlém vypnutí/odpojení disku a jednou se "jen " ztrácela matadata.
Ale je zajímavé, že Windowsům na to stačí jen jeden filesystém (NTFS), zatímco v Linuxu se pokaždý podělá něco jinýho. ;oD

Jenze za poslednich par tydnu je tech bugu i jen kolem tuxich FS troska vic ze? A vsechny maji vlastne stejneho jmenovatele - ruseni dlouhodobych LTS, a nulove testovani.

Ale jo, co mam v pameti, tak treba jeden takovy nepatrny "nezdokumentovany" atribut ;D. Ktery M$ zacal znicehoz nic pouzivat, coz vedlo k tomu, ze protoze ho pouzivala co si pamatuju nejaka appka, tak tem lidem to zmasakrovalo data.

root@rpiout:/var/log# uname -a
Linux rpiout 6.1.64-v7+ #1702 SMP Wed Nov 29 14:16:46 GMT 2023 armv7l GNU/Linux
root@rpiout:/var/log# uptime
14:41:03 up 7 days, 17:38, 2 users, load average: 0.04, 0.02, 0.00

Co ted? Da se z toho nejak vybruslit nebo me ceka reinstall?
Zatim se to tvari v pohode, logy jsou bez chyb... Ale po rebootu uz to asi nenabehne, co?

Je to problém pouze debianu nebo všech Linux distribucí?

Jen Debian + možno pár menších distier, ktoré sú bleeding edge....

napríklad Ubuntu aj Fedora update s touto chybou nemá.

Je to problem vsude tam, kde narazite na kernel 6.1.64 a 6.1.65... jinde ne.
V debianu je to uz fixle, ve stable repu se uz objevila 6.1.66 (a verze 12.3 debianu se moc neohrala, ted uz je to 12.4)

tieto zfs ext4 korelujem uz isty cas ;P s vesmirnym pocasim a nachadzam tam suvislosti :D

https://www.swpc.noaa.gov/communities/space-weather-enthusiasts-dashboard

S 6.1.66 mi to sice asi nemrší ext4, ale zato se mi přestal uspávat starý Thinkpad :-)

Ze by? ;⁠-⁠)
https://www.root.cz/zpravicky/v-jadre-se-v-patek-objevila-regrese-wifi-opraveno-v-6-6-6-a-6-1-67/

vysoce pravdepodobne :-)
https://lore.kernel.org/all/87sf4belmm.fsf@turtle.gmx.de/