Jaderné noviny – 3. 2. 2010 (diskuse)

[Michal Ludvig]

Citáty mi dneska daly zabrat... V jednom se mluví o nějakém "usond" a teprve po několikátém přečtení mi došlo že je to uprobe. No dobře, takže přepínám na fanaticky-ultra-český mód abych zbytku jaderných novin porozumněl a čtu dál. "Forky nejsou vždycky skvělé, ale upřímně je nepovažuji za špatnou věc a v Googlu jsem se pokusil tuto etiku vštěpovat." Sakra jaký fórky? Vzpomněl jsem si na "printer on fire" a podobné srandičky ale co s tím zase má společného google?! Čtu to podruhý, potřetí, AHA! Jsou to forky a ne fórky!!

Když musíme mít usondy tak si pro příště místo forků vyprošuju vidličky.

[Robert Krátký]

O usondách vs. uprobes se mluvilo pod předminulým dílem.

[guest]

a co tak pisat za prekladom (napr. do zatvorky, kurzivou) anglicky original? ci uz pre lepsie pochopenie alebo lepsie hladanie... :)

[Robert Krátký]

Tak to také ve většině případů je. Tentokrát to vypadlo asi právě kvůli tomu, jak se to probíralo minule.

[Robert Krátký]

Dal jsem tam místo toho odkaz.

[neaktivni]

Primlouvam se za original v zavorce. Precejenom je to prehlednejsi a rozhodne je to jednodussi a prijemnejsi, nez se ucit kazdy termin jeste v cestine (a v pripade jineho prekladatele navic v ruznych tvarech).

[Roger]

A já si vyprošuju shodu podmětu s přísudkem - "jak správci některé forky přitáhli zpátky (a jiné nechaly dělat si svoje)". Dík :)

[zulu]

správcy, neasi :)

[frr]

K tomu read-aheadu, ona to v Linuxu skutečně není žádná sláva. A mám pocit, že než aby vývojáři vymýšleli principiálně nedosažitelný univerzální algoritmus, který by fungoval od SD karty po špičkový externí RAID, měli by přihodit hrst laditelných proměnných do sysfs - třeba per block device nebo per mountpoint. On by si to pak každý mohl doladit podle svého, nějakou lepší chytristiku by mohl přihodit třeba UDEV apod. Než vyrábět v kernelu složitou heuristiku, která by se to snažila "odvodit z charakteristik protékající zátěže", proč nedat možnost uživateli, aby si řekl přesně, kterým směrem optimalizovat?
V debatě zásadně postrádám nuance jako zarovnání read-ahead transakcí na hranice strajpů u RAIDů (námět na jednu laditelnou proměnnou) nebo zmínku o tom, že při sekvenčním čtení skrz filesystém je potřeba jiný read-ahead na payload souboru a jiný na metadata (takže jediná hodnota udaná pro blokové zařízení je v principu blbě), a že pro optimální rychlost sekvenčního čtení by měl být k dispozici filesystém, který bude generovat minimum "nesekvenčních" seeků pro načítání metadat... optimální FS by musel mít metadata buď sekvenčně prokládaná v payloadu (snad BTRFS?), nebo by je musel mít v nějaké tabulce bokem (FAT64/EXFAT?) která se drží v RAM.
Pokud Linus osobně opakovaně tvrdí, že jeho benchmarkovou platformou je desktop na něčím pecku, a řeší se Window Manager, který dokolečka přepisuje maličký konfigurační soubor, tak těžko může být VM+FS+IOsched zároveň dobře optimalizovaný pro průchodnost serveru, který streamuje stovky paralelních downloadů velkých sekvenčních souborů. (Další laditelná proměnná: přednačtená data, poté co je user-space proces přijme voláním read(), není třeba dále kešovat, a lze je ihned zahodit.) A pak ty hlášky o "složitosti patchů pro zlepšení read-aheadu, ze které jdou oči šejdrem" - možná je to jenom projev toho, že ten problém skutečně *je* složitý, jednoduché recepty "na bázi nedbalé elegance" na něj nezabírají, je třeba ho řešit úpravami několika subsystémů kernelu ve vzájemné koordinaci.

[x14]

Dopředné čtení je prima - držím palečky. Mám hafo nevyužité paměti, když se rozumně použije, bude to super. Ale hlavně ať to nedopadne jako SuperFetch ve Vistách, to se občas chová vyloženě tragicky.