Názory k článku
Jádro 6.13 bude hlásit počet zaseklých úloh

Treba jednou peklo zamrzne a dockame se stavu, kdy pujde uninterruptible sleep ukoncit, at uz soft, ze to odblokuje wait a vrati syscall, nebo hard, ze to rovnou zabije volajici proces.

To není tak jednoduché, protože v jádře jsou ve stavu D rozpracované datové struktury. A násilné ukončení by muselo provést úklid, jenže by se na něco mohlo zapomenout a vysledkem by byly poškozené datové struktury (tj. mnohem větší problém).

Navíc, když je něco dlouho v D, znamená to vážný problém. A vážný problém znamená, že starosti o zaseklé procesy má admin až úplně na posledním místě.

25. 11. 2024, 21:44 editováno autorem komentáře

Mno, kdyz si odmyslim HW problemy, tak nejcastejsi dlouhodobejsi D-cka, na ktera jsem vzdycky narazil, je upadlej NFS mount (kde je hard default), pripadne SMR disk, ktery prave dostal kramy a jal se zametat. Popr. pomala velka mmc spolu s hodne pameti (==hodne dirty cache)

V vsech trech pripadech budu doufat, ze nikoho (kernel ani distribuci) nenapadne ten automaticky reboot zapinat by default.

Tak muj D problem naposled s qemu nad loopdev byl takovej ze reboot ani nesel udelat. Tak nevim zda ten automaticky by na tom byl nejak lepe - nebo je to vynuceny hard-reset bez nejakeho rozumneho vypinani.

Vzdy je lepsi mit moznost zachranit co se da... a ten reset udelat rizene. Samoztejme se bavime vicemene o manualnim zasahu. Otazkou je, kolik lidi se s tim v realu bude sr*t... aneb tipuju, ze vetsina rovnou sahne po resetovacim cudliku.

Jasne, ono je totiz mnohem jednodussi tomu stroji proste vytrhnout kabel z elektriny, protoze to je tak jediny co se s tim da delat.

To vubec nedava smysl, co pisete. To potom uz nebude "neprerusitelny" spanek :) /s

Ví někdo, jak to dělají jiné OS (zejména ten, jehož jméno zde nesmí být vysloveno) , že tenhle problém nemají?

Jakoze jine OS se nesekaji? :-) Ale jdete...

Cože, jaké sekání? Víš vůbec, o čem je řeč?

Jiste, na widlich hung I/O muze rovnou skoncit rovnou v BSOD. Takovy ne zcela dobrovolny hung_task_panic.

Máš k tomu nějaká relevantní data nebo máš jen salty náladu a tak tím obšťastnuješ svět? Z mé zkušenosti je Windows docela resilientní vůči problémům nesystémových disků, viděl jsem na vlastní oči i vytažení za chodu nvme, který rozhodně nebyl hotplug a rozdýchalo to v pohodě. Problémy se systémovým diskem snáší Linux i Windows stejně špatně, což by i člověk čekal.

Network attached bloková zařízení , třeba iscsi lun, jsou zcela bez problémů i na nestabilní síti. Řekl bych, že to je srovnatelné s Linuxem. Stejně tak "SAMBA". V tomto ohledu vskutku těžko najít něco horšího, než NFS.

Nieje to uplne ekvivalent. Ale napr. ked vo Windosws Clustery vytuhne heartbeat komunikacia niektoreho nodu z ostatnymi, tak na nom dojde zamerne k BSOD, abz sa rebootol. V danom pripade je totiy mensia skoda tvrdeho rebootu jedneho z nodou clustera, ako mat ten nod "nie uplne OK".

Viz: https://learn.microsoft.com/en-us/previous-versions/windows/desktop/mscs/cluster-hangrecoveryaction

Myslim ze aj na Linuxe si to svoj use case najde.

26. 11. 2024, 20:23 editováno autorem komentáře

Vygooglil jsem to. Ve Windows vůbec neexistuje koncept uninterruptable sleep. Všechny vrstvy - winapi, vfs, fs,... až po driver disku nebo síťovky, pokud se jedná o síťové IO, musí být napsaný tak, aby kdykoliv mohl přijít požadavek: mám v paží, že jsi zrovna uprostřed IO, uklidit po sobě chlívek a skončit.

Ne tak uplne ... vpodstate libovolna apppka ve widlich muze bloknout restart na tema "hej, musim neco dodelat, ted ne" (z toho je pak takova ta hlaska na tema ze apliace XYZ blokuje restart, legracni je, ze to dela treba taskmanager ...)

Mnoa pak tu jsou tardi, ktery tohle nechapou, netusej a pri kazdym zapnuti appky (putty portable trebas) ti zobrazej hlasku, ze ta aplikace nebyla minule korektne ukoncena.

A kdyz mu lidi 20 let pisou, at si tu hlasku strci nekam, kdyz ma v rukach na...no a neumi to, tak si porad mele svoji, ze za to muzou widle.

Na druhou stranu jako admin muzes ric restart bude proste hned ... a pak proste bude. Zatimco kdyz mas neco v Dckovyh stavu na tuxovi ... tak je to takovy, ze nekdy ti to teda jako reboot celyho systemu udela, ale nekdy ne. Coz je nehoraznost.

Neni to tak uplne pravda - volani se deli na synchronni a asynchronni. Jen u asynchronnich jde poslat legitimni request na zruseni.

Pak existuje par legacy volani ktere rusit nejdou, vice viz:

https://learn.microsoft.com/en-us/windows/win32/fileio/canceling-pending-i-o-operations

Jen trochu naznacim jak to dela DB Oracle coz sice neni OS, i kdyz je jeji jadro nazyva "kernel" a architektura je OS inspirovana.

Zatimco OS ma vlakna ktera sdili pamet, tak Oracle ma single-threaded procesy ktere pouzivaji shared memory segmenty. Pro synchnonizaci k pristupu ke strukturam ve sdilene pameti se pouziva "latch". Latch je zamek, ktery obsahuje navic metadata o typu operace a pointer na cleanup funkci.

Pokud nejaky proces pritupuje ke strukture ve sdilene pameti tak behem zamykani ulozi predchozi hodnotu, typ operace a pointer na cleanup funkci. Pokud proces nejakym zpusobem selze tak dedikovany cleanup proces uvedete metadata do konzistentniho stavu. Latche jsou navic ocislovane, pokud uz vlastnite latch cislem X, tak muzete zamknout neco s latchem X+1 a vetsi. To garantuje, ze na zamykani vnitrnich datovych struktur nikdy nemuze vzniknout deadlock.
Cele je to udelane tak, ze muzete "kterykoliv" process kdykoliv zabit pres "kill-9" a databaze by to mela vydychat a uvest vnitrni pametove struktury do konzistentniho stavu.

Cele se to dost blbe programuje a je to narocne na testovani. Je potreba pouzivat ruzne bariery aby kompilator skutecne ulozil promenne do pameti, aby nic nezahodil a aby se operace skutecne provedly s tom poradi jak byly naprogramovane.