Jaderné noviny – 11. 9. 2014: SIGKILL a pomalé zjišťování zařízení (diskuse)

[Michal Kubeček]

Výsledná diskuse se rozprostřela po několika seznamech a sledování chyb

Ty "seznamy" mají být mailing listy? A nemohlo by to být aspoň něco jako "systémy (pro) sledování chyb", aby k pochopení věty nebyl potřeba překlad zpátky do angličtiny?

[trekker.dk]

Konspirační teorie: Luboš nemá čas překládat, tak publikuje pod falešným jménem něco, co má přesvědčit čtenáře, aby se někdo zdobrovolnil.

[xkucf03]

.set_mux = pcs_sex_mux,

A tohle šlo zkompilovat?

[pavele]

Podle všeho nemá systemd-udev neomezenou trpělivost; při načítání modulu zařízení spustí 30sekundový časovač (zkrácený z loňských 3 minut)...

[mankind_boost]

[pavlix]

Je tam nějaká souvislost, která mi uniká?

[pavele]

1. Načítání modulu nefunguje -> Udělej přesný počet kliků -> Otoč se na SSV rychlostí přiměřenou -> Čekej přiměřený čas -> Pokračuj.

2. Pokud to nefunguje, nechej to opravit jadernými vývojáři - jasná chyba jádra.

To se v programátorské praxi běžně používají takové triky?

[frr]

Asynchronní detekce *všech* blokových zařízení - to je slovo do pranice

Zatím tohle fungovalo jenom na USB - kdo jste zkoušeli bastlit distro, které by bootovalo z USB CD nebo HDD, asi jste si všimli. Všimli jste si, že z toho nejde přímo mountovat root, protože USB disky v tu chvíli prostě ještě nejsou "nalezené" (trvá to dalších pár vteřin). Takže mountnout ramdisk a pak olizovat nějakým skriptem, kdy se to chytne (nebo čekat dlouhý pevný čas - fuj).

Čili "asynchronní detekci" vnímám tak, že časem se tohle bude týkat mnoha direct-attached diskových médií. A nejde jenom o mountnutí root volume, jde obecně o celý fstab i jakékoli další svazky mountované jinými způsoby. V zásadě dneska spousta servisek (třeba Samba) při svém startu (init skriptem) považuje za samozřejmé, že jsou v okamžiku startu servisky mountnuté všechny svazky, které serviska potřebuje ke své práci. Pokud tenhle předpoklad přestane platit, je potřeba nějak navázat servisky na přítomnost namountovaných svazků... bude veselo Vlastně na to stačí pár řádek, grepnout něco z výstupu "mount" apod. - nebo by to možná šlo nějak zajímavěji, mohl by se pro to zřídit nějaký systémový framework na bázi událostí, možná už dokonce existuje a jmenuje se udev...

Třeba auto-fsck při startu to má ošetřeno tak, že dokud nedoběhnou všechny instance fsck, visí systém "v singlu", nezačne bootovat zbytek user space.

Třeba přímo připojené HDD jsou ještě docela rychlé, ale nejsem si jist, zda by se detekce a inquiry stíhala asynchronně do okamžiku, kdy se jádro dostane do bodu "připraven mountnout root".

Že se nestihne loadnout firmware a projít strom zařízení na nějakém větším DAS RAIDu nebo SAN síti, to mi přijde vcelku přirozené - a nemusí to trvat tři minuty, stačí pár vteřin a je vymalováno.

Možná by kernel při mountování rootu nemusel házet hned panic, možná by mohl nějakou dobu čekat na "kýžený root volume". Ale jak říkám - to je jenom první překážka v řadě. Pravda je, že ty následující už žijí v user space.

[R]

Napad je to dobry - kym jeden driver caka napriklad na rozbehnutie diskov (to mozu byt desiatky sekund), takt dalsie mozu robit nejaku uzitocnu cinnost. Otazkou zostava, ako to bude fungovat v praxi.

[Tom K]

Otazkou hlavne zustava, jak se s vyporadat se stavem, kdy ten dalsi potrebuje prave ty roztocene disky. Cimz se dostavame k ekvivalentu serioveho a paralelniho initu, ale v mnohem komplikovanejsim kusu kodu, ktery obsahuje daleko vic zavislosti a musi fungovat spolehlive na mnoha platformach.

On je rozdil si na tohle hrat v userspace, kde zjevne jen malo lidi trapi, ze nova vec (napr systemd) rozbije spoustu starych. A je rozdil udelat totez v kernelu, ktery nema povoleno nic rozbit (zkuste navrhnout, ze kernel v tuhle chvili omezi funkcionalitu nejake sve casti treba na tretinu jen proto, ze se to jednomu vyvojari zdalo fajn).

V kernelu zatim asynchroni inicializace zarizeni neni, protoze v praxi prinasi vic problemu nez uzitku.

[R]

Roztocene disky nepotrebuje v kerneli ziadny dalsi driver. Rovnako ako USB disky, ktore sa inicializuju v lubovolnom momente. Dalsie akcie sa vyvolaju ako nasledok toho, ze sa objavil disk.

[...]

stejne blbe jako kdyz zarizeni zmizi a zase se objevi, protoze si kernel usmyslel, ze provede reset radice.

[David Jaša]

V zásadě dneska spousta servisek (třeba Samba) při svém startu (init skriptem) považuje za samozřejmé, že jsou v okamžiku startu servisky mountnuté všechny svazky, které serviska potřebuje ke své práci.

Zrovna tohle je v systemd světě řešitelné velmi jednoduše: přidáš do unit souboru dotyčné služby tvrdou závislost na daném zařízení a je to.

[mankind_boost]

+1

[R]

Takze vsetky samba shary, ktore su namountovane particie, budu na troch miestach? fstab, smb.conf a este nejaky unit?

[David Jaša]

Alternativou v sysv je fstab, smb.conf a samo domo skript, který by ti ohlídal, aby se samba spouštěla až po namontování dotyčných partišen... Aneb systemd tady není to, co ti nutí změnu, systemd ti umožňuje se změně kernelu popisované v TFA jednoduše přizpůsobit!

[martian]

Zrovna tohle je v systemd světě řešitelné velmi jednoduše

Takze, az si to precita Lenart, bude uz len otazkou casu, kedy systemd integruje kernel. (Nakolko je velmi nepravdepodobne, ze by kernel integroval systemd.)

A naschval sa nevyjadrujem, ci to bude dobre, alebo zle... Zacinat so systemd v jadernych novinach je zaruceny flamewar. Skoda, ze sa nepocitaju komentar "hits"

[Honz]

Celkem normální docela ujde
Tohle by asi chtělo trochu učesat...