Vlákno názorů k článku
Jádro 6.13 bude hlásit počet zaseklých úloh
od miho - Ví někdo, jak to dělají jiné OS (zejména...
-
DannyStříbrný podporovatelJiste, 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.
-
Ak mete v DAGu viac serverov, tvrdy reboot moze napachat menej skody, ako ked server "podivne vytuhnuty".
U Windows Clusteru sa toto spravanie da nastavit:
https://learn.microsoft.com/en-us/previous-versions/windows/desktop/mscs/cluster-hangrecoveryaction
Kazdopadne BSOD je asi najrychlejsi mozny reboot aky na Windowse da spravit. Ak je niekde dohlad 24/7 co sa vie dat dokopy vytuhnuty nod, asi BSOD nieje to prave. Ale ked mate adminov len 8/5 tak je lepsie nechat BSOD, ako v podnelok rano zistit ze Vam cely vikend nechodili maily...
-
DannyStříbrný podporovatel
Tohle si ma zhodnotit administrator po zvazeni vsech pro a proti a ne, ze nejaka pomazana hlava v Redmondu usnese, ze to tak proste bude.
Pokud nekde funguji v rezimu 8/5, tak jim je pravdepodobne vcelku putna, ze pres vikend ty maily nechodi. SMTP ma uz od doby kamenne mechanismy, jak se s tim vyporadat.
-
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.
