Jaderné noviny – 3. 4. 2014: Diskové bloky větší než 4K (diskuse)

[fritz]

Todleto bylo uvolněno zdarma už 10. dubna a dneska máme 22. dubna. Nějak dlouho trval překlad. Takovýdle článek s tím velkým zpožděním nemá už žádnou cenu.

[Honza Jaroš]

Tak to nečtěte.

Pro redakci: díky za překlad.

[R]

Nikto ti nebrani to nabuduce hned po zverejneni prelozit.

[Punny]

ach, typicky Čech :D hovno udela, ale vsechno okolo pomlouva :D

[pavlix]

Nikoliv. Typický Čech přijde do diskuze, kde se mu nějaký příspěvek nelíbí, a jeho autora označí za typického Čecha.

[Punny]

takze souhlasis s tim, ze tu mame vsichni anonymne pomlouvat kazdy clanek/zpravicku? A ano nelibi se mi prispevek, ktery odrazuje od vydani dalsiho...az tebe budu jebat, ze jsi neco postnul s tydenim opozdenim, jsem zvedav jaky k tomu budes mit postoj...

[pavlix]

takze souhlasis s tim, ze tu mame vsichni anonymne pomlouvat kazdy clanek/zpravicku?

Kvalitní matroš, kde se to shání?

[noflame_just_fun:]

a tohleto uz je kandidat na typicky rekurzivniho cecha

[pavlix]

You don't say :).

[tecik]

Nj na ceskem foru, s ceskym komentarem se da ocekavat reakce typickeho cecha Ale ted vazne, proc dotycny nadava, vzdyt si muze precist original.

[pet]

To, že tu už zase někdo pindá něco o dlouho trvajícím překladu mě pohnulo k tomu abych vyjádřil poděkování Luboši Doleželovi i redakci za tyto překlady. Pro mne mají význam i kdyby byly ještě zpožděnější. Děkuji.

[Xerces]

Tak tak. P.S.: To s tím Facebookem je míněno vážně, nebo je to nějakej druh humoru?

[Michal Kubeček]

Zkuste hádat…

Date: Tue, 1 Apr 2014 10:41:04 -0400

[karel.k001]

Ja taky dekuju za preklady. A btw. neslo by zase zaradit preklady XKCD?

[Luboš Doležel (Doli)]

Pokusím se, navalilo se toho na mě letos hrozně moc

[Petr Tomášek]

Řekl bych, že ten opožděný překlad je schválně, je to tak domluveno s původním autorem.

[trekker.dk]

AFAIK je domluveno, že překlad nevyjde dřív, než je originál uvolněn zdarma. Zbytek záleží na tom, kolik času má ten, kdo překládá.

[Luboš Doležel (Doli)]

Překládám to vždy večer před vydáním, takže se trvale drží ten samý skluz už několik let. A díky němu to pěkně vychází tak, že v prosinci není žádný výpadek, který mám pocit, že je v originálu "doháněn" dvěma čísly krátce po sobě.

[pavlix]

Ano, tohle mě osobně neskutečně vytáčí. Naše konfigurační prostředí je tou naprosto nejhorší částí jádra a není to kvůli tomu, že by Kconfig byl složitý jazyk. Je to kvůli tomu, že odrazuje lidi od sestavování vlastního jádra a testování, jelikož je nesmírně složité odpovídat na naše otázky a vypadá to, že vyzýváme lidi k zapínání funkcí, které jsou zbytečné a jen dělají sestavování pomalejším a obtížnějším.

Svatá pravda. I když mě na konfiguraci kernelu nejvíc vadí to, že je to debilní klikaču. Už delší dobu toužím po nástroji, který by dokázal konfigurovat jádro na základě pevně daných (statických) požadavků a nikoliv prolézáním nějakého idiotského menu. Pak by bylo možné tyto požadavky sestavovat například z různých software balíků, které dnes v lepším případě poskytují nástroj pro kontrolu zda je kernel připravený pro použití daného software.

[j]

Ona je to tragedie v mnoha ohledech ... velmi casto narazim na to, ze po me nejaka apka chce nekde neco povolit, a ono to tam neni, protoze neni povoleno neco jinyho, a dohledavat co ze to ma povoleno byt ... je casto na velmi dlouhy googleni. Nemluve o tom, ze appka casto neni sync s aktualnim kernelem, takze prislusna volba je jinde nez aplikace popisuje ...

Navic komenty k jednotlivym volbam jsou tak uzasne vserikajici ("pokud to nepotrebujete tak to nechte byt") ...

Takze to prevazne konci tim, ze clovek "projistotu" prekompiluje uplne vsechno.

[Bystroushaak]

Tohle by byl docela dobrý projekt pro GSoC, nebo nějakou podobnou akci. Nemělo by to být moc těžké a přitom by to usnadnilo život mnoha lidem.

[Radek Podgorny]

pouzij v tom menu lomitko a vyhledej flag, o ktery ti jde. nejen, ze uvidis, kde presne ho hledat, ale taky tam jsou vypsane zavislosti...

[pavlix]

Není tvůj stručný návod na použití make menuconfig tak trochu mimo téma tohoto vlákna?

[j]

Ehm ... ja bych rek, ze vedet, ze volba XYZ ma byt nekde v a-> b -> c ... je mi platny ja mrtvymu zimnik, kdyz tam ta polozka neni ... protoze nekde v a -> k -> l neni zapnuta volba KLM. Coz samozrejme nikde nezjistim, protoze to jaksi nikde neni napsany. Ano, muzu zacit zkoumat konfiguracni zdrojak, ja vim ...

A tohle v kernelu neni vyjimka, ale spis pravidlo. Vyjimkou je spis to, ze je treba povolit nejakou vetev stromu aby se clovek dostal k jejim prvkum. Pravidlem je to, ze jednotlivy prvky ovlivnujou vetve uplne mimo ...

Takze zcela bezne nastavaji varianty, ze clovek nekde neco povoli, a nekde kde uz byl ... se objevi znicehoz nic dalsi hromada voleb, alternativne, clovek nekde neco zakaze ... a nekde zcela jinde mu zcela bez upozorneni hromada voleb zmizi.

Takze pak nezbyva nez strejda guugl ...a zjistovani, proc to ci ono neni tam, kde by byt melo ...

Osobne naprosto nechapu, proc nemuzou byt zobrazeny jednoduse volby vsechny ... a pokud zaskrtnu neco, co je na necem zavisly, tak ocekavam hlaseni, ze je treba taky povolit ... a dotaz, zda to pro me ma konfigurator udelat. A samo, jako bonus nejaky upozorneni pri ukladani, zda je nebo neni konfigurace z pohledu tehle zavislosti validni.

[trekker.dk]

protoze nekde v a -> k -> l neni zapnuta volba KLM. Coz samozrejme nikde nezjistim, protoze to jaksi nikde neni napsany.

Zvýrazním tu část předchozího příspěvku, kterou jste zjevně minul: ale taky tam jsou vypsane zavislosti.... Stačilo to zkusit.

[Kvakor]

Ehm ... ja bych rek, ze vedet, ze volba XYZ ma byt nekde v a-> b -> c ... je mi platny ja mrtvymu zimnik, kdyz tam ta polozka neni ... protoze nekde v a -> k -> l neni zapnuta volba KLM. Coz samozrejme nikde nezjistim, protoze to jaksi nikde neni napsany. Ano, muzu zacit zkoumat konfiguracni zdrojak, ja vim ... ... Osobne naprosto nechapu, proc nemuzou byt zobrazeny jednoduse volby vsechny ... a pokud zaskrtnu neco, co je na necem zavisly, tak ocekavam hlaseni, ze je treba taky povolit ... a dotaz, zda to pro me ma konfigurator udelat. A samo, jako bonus nejaky upozorneni pri ukladani, zda je nebo neni konfigurace z pohledu tehle zavislosti validni.

No mně osobně vždy pomohlo projít soubory Kconfig a dohledat si to tam, i když je pravda, že možnost zobrazit skryté volby v omezeném měřítku (například jen ty platné pro danou platformu) by se občas hodila. Ale jinak mi stávající rozhraní pro konfiguraci jádra vyhovuje, i když je pravda, že je to nejspíš z toho důvodu, že to dělám dost často a už mi to ani nepřijde (pamatuju ještě doby, kdy nebyla podpora modulů a vlastní konfigurace jádra byla na PC nutnost).

Osobně považuju za mnohem horší stav, kdy jádro nejde přeložit, protože nějaký kód něco potřebuje, ale nemá to nastavené v KConfigu, nicméně to je něco, s čím se u "normálních" verzí jádra (tj. vanilla a distribučních) naštěstí nesetkáte.

[pavlix]

Hlavně já bych to potřeboval v Gentoo nějak naintegrovat s userspace balíčky abych nemusel pokaždé znovu řešit závislosti userspace na konkrétních modulech. Představoval bych si fúzi z několika zdrojů.

Mám v Gentoo zvolený desktopový profil. Z toho by pocházela část konfigurace běžná pro desktopové systémy. Balíčky by nahrávaly do určeného adresáře soubory požadavků. Takto by se vyřešily závislosti pro projekty jako je openrc, systemd, qemu, lxc, libvirt a podobné. Některé závislosti by se daly pověsit i na nástroje jako iproute, iptables, ipset a mohly by se řídit pomocí use flagů. Na některé běžné kombinace by se daly vytvořit virtuální balíky opět s use flagy.

No a k tomu všemu bych si vytvořil vlastní požadavky jako když instaluju další balíky do systému. Případně by šlo vytvořit nějaké overrides pokud naopak nějakou závislost chci ignorovat. Pokud by to fungovalo tímto způsobem, bylo by možné v distribuci, kde se kompiluje vlastní jádro, udržovat užitečný systém profilů, závislostí a vlastních požadavků.

[aceman]

Akurat by tie aplikacie nestihali so zmenami kernelu, kde sa pravidelne premonavavaju tie volby.

A po druhe, baliky ako iptables by si zadali poziadavky, napr. na podporu vsetkych protokolov a cielov a funkcii v netfilteri/firewalle v kerneli (ci ako sa to teraz vola). A pritom na konkretnom pocitaci moze admin potrebovat len malo mnozinu. Kernel moze byt zamerne nakonfigurovany len na urcite funkcie, aby aplikacie nedostali vsetko co potrebuju (ked im to admin nechce dat). Takze zase by sa tento system musel nejako dat obist.

[pavlix]

Akurat by tie aplikacie nestihali so zmenami kernelu, kde sa pravidelne premonavavaju tie volby.

Zajímavé je, že teď mnohé stíhají poskytovat nástroje na kontrolu, zda je kernel správně nastavený. Netvrdím, že by se to obešlo bez problémů nebo že je to úplně jednoduché. To bych nad tím nepřemýšlel a prostě bych si to napsal a začal to tlačit alespoň v tom Gentoo jako součást balíků.

A po druhe, baliky ako iptables by si zadali poziadavky, napr. na podporu vsetkych protokolov a cielov a funkcii v netfilteri/firewalle v kerneli (ci ako sa to teraz vola). A pritom na konkretnom pocitaci moze admin potrebovat len malo mnozinu. Kernel moze byt zamerne nakonfigurovany len na urcite funkcie, aby aplikacie nedostali vsetko co potrebuju (ked im to admin nechce dat). Takze zase by sa tento system musel nejako dat obist.

Nesouhlasím, že je dobrý nápad aby iptables bezpodmínečně záviselo na všech volbách. Nicméně píšeš o problémech, jejichž možná řešení jsem již nastínil.

Takze zase by sa tento system musel nejako dat obist.

I na toto už jsem odpověděl, viz druhá věta třetího odstavce.

[pc2005]

Jo na nconfig kernelu měto menu taky docela vadí, nejhorší je, když to prolézám lineárně a některá volba skryje nebo odkryje volbu jinde v menu, kde už jsem byl.

Jinak problém těch balíků je ale v tom, že ti stejně zbyde hromada voleb, na kterých žádný userspace balík nezávisí nebo je k dispozici víc variant.

[pavlix]

Jinak problém těch balíků je ale v tom, že ti stejně zbyde hromada voleb, na kterých žádný userspace balík nezávisí nebo je k dispozici víc variant.

Popravdě řečeno nepatřím mezi ty, kteří chtějí nastavovat každou poslední volbu jádra. Od toho je rozumné výchozí nastavení, případně volba některého dobře postaveného profilu dle účelu stroje plus těch pár změn, co potřebuju udělat. Už jsem dokonce uvažoval, že kvůli debilitě konfigurace jádra budu používat jádro z nějaké binární distribuce, abych se celému tomu martyriu vyhnul.

Osobně bych si kvůli různým experimentům zapnul pár voleb týkajících se sítí a zbytek ať se klidně řídí hardware, balíčky, profilem a výchozí konfigurací.

[pc2005]

No já jsem na svým domácím počítači vždycky použil .config ze starýho jádra a rychle nastavil nové volby. Je to sice trochu prasárna, ale funguje. A i kdyby, tak konfigurace jádra od nuly jednou za rok není zas tak hrozná (projet všechny volby zabere tak jedno odpoledne).

Ad hardware: Nechtěl bych být ten, co bude spravovat databázi například nových USB donglů .

[pavlix]

No já jsem na svým domácím počítači vždycky použil .config ze starýho jádra a rychle nastavil nové volby. Je to sice trochu prasárna, ale funguje.

Ano, to dělám, a výsledky jsou nevalné a nepředvídatelné.

A i kdyby, tak konfigurace jádra od nuly jednou za rok není zas tak hrozná (projet všechny volby zabere tak jedno odpoledne).

Možná jsi génius, ale já osobně nejsem schopný takto vyrobit deterministickou konfiguraci a typicky na první pokus ani plně funkční konfiguraci. Celý ten proces mě natolik zdržuje ještě dlouho po prvotní konfiguraci jádra, že se do nějaké důsledné optimalizace radši ani nepouštím. Věřím tomu, že to mnohé odradí i od celého procesu a vím o lidech, kteří na Gentoo používají distribuční jádro z jiné distribuce.

Nechtěl bych být ten, co bude spravovat databázi například nových USB donglů

Ony jsou v jádře off by default? A i kdyby, nedá se jejich databáze nějak více či méně deterministicky vyrobit ze zdrojáků jádra?

[trubicoid]

No já jsem na svým domácím počítači vždycky použil .config ze starýho jádra a rychle nastavil nové volby. Je to sice trochu prasárna, ale funguje.

Ano, to dělám, a výsledky jsou nevalné a nepředvídatelné.

men to tak fachci make oldconfig

Nechtěl bych být ten, co bude spravovat databázi například nových USB donglů

Ony jsou v jádře off by default? A i kdyby, nedá se jejich databáze nějak více či méně deterministicky vyrobit ze zdrojáků jádra?

no usb mass-storage snad zadnou databazi nepotrebuje jak konkurencni widle

jestli myslis usb.ids, to bylo v usbutils a ted je to v hwids

[pavlix]

Jak už jsem psal, výsledky jsou nevalné a už vůbec neodpovídají záměru, který jsem zde v diskuzi popsal. Pokud jde o USB, to si pořešte s pc2005, já v tom žádný problém nevidím.

[pc2005]

Já myslel hlavně věci jako dvb-t dongly a dvb-t obecně (naposled teda spíš PCI karty). Ty mají různé quirk parametry pro modprobe nebo konfigurační volbu pro zdroják. Mnoho PCI karet například nemá eeprom a subsystem ID, takže hlavní čip je známý, ale třeba použitý tuner už ne. A u reverznuté komunikace tunerů (nejen) můžou být v jádře dva vzájemně výlučné ovladače. Myslím, že v jádře byly ve Staging jednou duplicitní drivery pro ralink a realtek wifi.

[pc2005]

U mě je na funkčních architekturách obvykle problém pouze s tím, že pro disk zapomenu přidat některou vyžadovanou vrstvu (třeba scsi nebo libata). Ale jestli kompiluješ pro nějaké větší množství strojů, tak to chápu. Hardware hlavního stroje si ale pamatuju bezproblému.

Celý ten proces mě natolik zdržuje ještě dlouho po prvotní konfiguraci jádra, že se do nějaké důsledné optimalizace radši ani nepouštím.

Tak to já mám taky tunu bordelu, ale některý defaultní věci mě vyloženě štvou (obvykle "M" vs. "Y" nebo tuna nepotřebných driverů zařízení).

Věřím tomu, že to mnohé odradí i od celého procesu a vím o lidech, kteří na Gentoo používají distribuční jádro z jiné distribuce.

Na Gentoo? Tak to mě docela překvapilo :-O . Tam bych naopak čekal lidi, co to budou štelovat i třeba za cenu úpravy zdrojáků .

Ony jsou v jádře off by default?

No právě když už ruční kompilace, tak všechno, co nemám doma vypnout nebo připravit na kompilaci jako modul.

[pavlix]

Na Gentoo? Tak to mě docela překvapilo :-O . Tam bych naopak čekal lidi, co to budou štelovat i třeba za cenu úpravy zdrojáků .

Je z části i tím, že na konfiguraci jádra neexistuje žádná rozumná automatizace, teda pokud nepočítáš genkernel s mrproper a bez ruční konfigurace, ale ani to zřejmě nedává výsledky srovnatelné s distribučními jádry.

Jinak nevidím jediný důvod, proč štelovat jádro do posledního detailu, pokud se to dělá takhle blbě a přitom mi to vůbec nic nepřinese.

No právě když už ruční kompilace, tak všechno, co nemám doma vypnout nebo připravit na kompilaci jako modul.

Ony jsou nějaké USB srágorky ve výchozí konfiguraci zakompilované?

[pc2005]

Ony jsou nějaké USB srágorky ve výchozí konfiguraci zakompilované?

Ano, v i386_defconfig mám dost zbytečných věcí defaultně zaplých. Jsou tam i usb zařízení, ale přímo DVB-T tam nejsou, protože celý drivers/media je defaultně vyplý. Pokud se zapne, tak se například kompilují všechny tunery a frontendy.

[pavlix]

Osobně bych vnímal zakompilované drivery pro cokoliv co se připojuje přes USB kromě základních zařízení pro interakci mezi uživatelem a systémem za bug.

[Michal Kubeček]

Ono by všeobecně přímo do image mělo přijít jen to, co (a) jako modul přeložit nejde nebo (b) tak jako tak používají skoro všichni, takže modul by jen zbytečně (ještě víc) zvětšil initrd. Jenže zauditovat celou konfiguraci, to už je dnes mnoho člověkohodin práce…

[pavlix]

Takže v podstatě potvrzuješ mojí domněnku, že se jedná o bug a je lepší ho řešit ve výchozí konfiguraci jádra než ručním procházením menuconfigu při lokálních buildech. Jestliže si pc2005 dává práci s vlastním auditem, nebylo by úplně špatné kdyby své výsledky poskytnul třeba ve formě patche měnícího výchozí konfiguraci. Ulehčil by si tím práci do budoucna.

[pc2005]

Problém je, že se nelze dohodnout, co je důležité a co ne. Já třeba CONFIG_HID_NTRIG nemám a nikdy jsem o tom neslyšel (HID, defaultně "y") a přitom to teoreticky může být pro řadu lidí jedinej způsob jak ovládat počítač (podle popisku je to nějakej touch-screen driver). Na druhou stranu já mám v jádře PLIP a už jsem ho roky nepoužil.

I kdybych sem pastnul .config (prastaré jádro 3.5), tak to bude bezpracně fungovat jen na jedné desce a navíc na jedné určité konfiguraci hw.

BTW myslím, že jsem v jedněch starých jaderných novinách četl, že defconfigy pro různé desky (ARM) nejsou zrovna oblíbené, protože je nikdo neudržuje a během času se dostaly mimo mísu.

[pavlix]

Problém je, že se nelze dohodnout, co je důležité a co ne.

V kontextu toho, co jsem psal výše to problém právě není. Výsledkem konfigurace jádra by totiž byla kombinace výchozího nastavení, změn specifických pro hardware a uživatelsky definovaných změn. Pokaždé když dokážeš vyjmenovat dvě nebo tři věci, které bys potřeboval mít zakompilované, lze je bez problémů zapsat do těch uživatelsky definovaných změn, pokud už nejsou součástí hardware profilu.

[pc2005]

Aha já ty věci totiž vyjmenovat nedokážu, prostě když konfiguruju jádro, tak si čtu a říkám si: "to by se mi hodilo, tohle a možná tohle...", tedy pro uspokojivou konfiguraci stejně musím prolízt celý jádro. Funguje to tedy jako hledání novinek . Ale asi by to šlo udělat nějakým obecným diffem pro všechny verze a pak vytříděním novinek. Takže moje představa, co by mohl/měl ten systém splňovat (warning subjektivní, nepřesné a napřeskáčku ):

• Kompatibilita se starým způsobem konfigurace (moc kritická vlastnost, aby byla zahozena)
  • Kompatibilita se všemi GNU/Linux OS (já používám slackware, takže minimální balíčkovací podpora )
  • Podpora Kconfig helpů (mnohdy jsem teprve z nich pochopil zda tuhle volbu povolit nebo ne)
  • Konfigurátor podřízen libovůli změn syntaxe/voleb/adresářové struktury kernelu a ne naopak (ledaže by šlo přesvědčit Linuse ), kompatibilní pro všechny verze
  • Nejvíc kompilací udělá IMHO vývojář driverů, takže dynamická detekce Kconfig z nonvanilla offline repozitáře (stylem "kruci chyba v Kconfig" jsem ztratil pár desítek kompilací )
• Minimální závislosti na dalším softwaru než kernel, ideálně přímo přes skripty kernelu (tedy limitně nulová závislost na pythonu, perlu, Xek apod.)
• Detekce současné konfigurace:
  • Databáze voleb všech starých verzí a jejich změna na nové (pamatuju si, jak se dělaly velké přesuny USB driverů)
  • Mnoho zařízení funguje jen pro učité parametry (jako tuner=XX, card=YY apod.), takže skenování /etc/modprobe.d/ (to se bude hodně lidem "líbit")
  • Samozřejmě import starého .config (dá se spolehnout na verzi v komentáři?)
  • Detekce hardware (stačí lshw?, lsusb tuším nefunguje vždy - vyžaduje nějakou usb debug vrstvu)
• Lehké hledání podle mnoha parametrů a obousměrné závislosti
  • Chci povolit celý USB subsystém enablováním jednoho USB driveru (má se po opětném disablování celý subsystém vypnout? co když to tak chtít nebudu)
  • Chci vidět na čem závisí tenhle driver (to umí i nconfig i když dost blbě)
  • Chci zobrazit všechny "m" a z nich vybrat nově přidaný driver, ale jen ten, na kterém nezávisí funkčnost systému (to by eliminovalo způsob jak jsem například našel emulátor zvukovky přes pcspeaker)
  • Hlášení všech kolizí a nekompatibilit (kompilace 386 konfigurace na nové post386 verzi kernelu), konfigurátor nesmí myslet za uživatele (jinak ztráta konfiguračního cyklu)
• Databáze známých problémů, jinak pomocí globálního nastavení OS nenabootuje a možná bude nutno ručně prolézat volby
  • Opravdu jde udělat stabilní databázi, kterou lidi stíhají updatovat? V případě "benevolentního diktátora" na něm bude záviset funkčnost kompilace kernelu pro všechny jádra: příliš vysoká homogenita konfigurace, syslení patchů ubuntu, "bene-dikt" nesmí zdržovat vývoj, NSA?
  • Nějak vyřešit podporu 10+ starých MB (třeba moje k7s5a měla (nejen) apic=off problémy a poprvé jsem to nevěděl a musel jsem rekompilovat). V případě podpory jen nejnovějších verzí si to budu stejně muset objevit nastavit sám nebo se dohadovat s "bene-diktem" o zařazení
• Databáze uživatelského nastavení pro věci, co nelze detekovat, odhadnout (?), nejsou v online databázi
  • Opět kompatibilita pro všechny verze kernelu
• Co offline konfigurace?

No nic tak jsem se trochu rozepsal . Pokud by to chtěl někdo zkusit, tak hodně štěstí, ja na to nemám čas. Ale rád mu pošlu všechny budoucí .configy (tedy pokud mi to bude fungovat na slacku přes ssh konzoli třeba).

[pavlix]

Aha já ty věci totiž vyjmenovat nedokážu, prostě když konfiguruju jádro, tak si čtu a říkám si: "to by se mi hodilo, tohle a možná tohle...", tedy pro uspokojivou konfiguraci stejně musím prolízt celý jádro. Funguje to tedy jako hledání novinek .

Taky jsem si vyzkoušel LFS a ještě to neznamená, že ho považuju za ideální způsob přípravy linuxové instalace. Tohle mi přijde daleko horší než LFS.

Kompatibilita se starým způsobem konfigurace (moc kritická vlastnost, aby byla zahozena)

Triviální, stačí dále používat .config a z pohledu ostatních nástrojů se nic nemění.

Minimální závislosti na dalším softwaru než kernel, ideálně přímo přes skripty kernelu (tedy limitně nulová závislost na pythonu, perlu, Xek apod.)

Osobně považuju za nepodstatné. Všechny konfigurace jádra dělám z plně funkčního systému.

Databáze voleb všech starých verzí a jejich změna na nové (pamatuju si, jak se dělaly velké přesuny USB driverů)

Nevidím jako potřebné. Není problém udělat třeba hardware konfiguraci variantní pro více různých verzí, stačí uvádět všechny alternativy.

Detekce hardware (stačí lshw?, lsusb tuším nefunguje vždy - vyžaduje nějakou usb debug vrstvu)

Nepovažuju za nutné. Může být řešeno samostatným software s exportem do daného formátu.

Chci povolit celý USB subsystém enablováním jednoho USB driveru (má se po opětném disablování celý subsystém vypnout? co když to tak chtít nebudu)

V systému, který jsem popisoval žádné opětovné disablování neexistuje. Existují jen pravidla ze kterých se vytvoří celá konfigurace.

Chci vidět na čem závisí tenhle driver (to umí i nconfig i když dost blbě)

Nesmysl. Systém, který jsem popisoval není ani prohlížeč závislostí ani interaktivní editor konfigurace. Ty už existují.

Hlášení všech kolizí a nekompatibilit

To by měla být samozřejmost, ale to zvládne samostatný nástroj. Není už takový k dispozici?

Databáze známých problémů, jinak pomocí globálního nastavení OS nenabootuje a možná bude nutno ručně prolézat volby

Na to by měl teoreticky stačit samostatný nástroj, ale integrace je možná.

Nějak vyřešit podporu 10+ starých MB (třeba moje k7s5a měla (nejen) apic=off problémy a poprvé jsem to nevěděl a musel jsem rekompilovat).

Jasně. A jako vedlejší efekt vyřešit všechny problémy světa. Tady opravdu doufám, že si děláš prdel.

Databáze uživatelského nastavení pro věci, co nelze detekovat, odhadnout (?), nejsou v online databáz

Také okrajové sračky má smysl řešit teprve kdyby byl nějaký nástroj k dispozici.

Co offline konfigurace?

Konfigurace pokud vím už offline probíhá.

No nic tak jsem se trochu rozepsal .

Především mám podle některých poznámek obavu, že jsi popisoval něco zcela jiného než co jsem popisoval. Nesliboval jsem že budu něco takového zkoušet, ale pokud ano, tvým představám to zcela jistě odpovídat nebude.

[pc2005]

Tak ideální způsob instalace linuxu je obvykle použití distribučního jádra.

Ty navrhuješ, že přidáš něco jako use flagy a seznam závislostí do balíčkovacího systému a to tak, že to bude řídit konfiguraci kernelu a bude to statické. Já tvrdím, že pro určité konfigurace nebo při updatu na novou verzi jádra není možné tu konfiguraci deterministicky vytvořit (aby fungovala na první pokus) ledaže bys měl:

1. Databázi vyjímek (neboli předchozích pokusů od lidí, co to dali až na n-tý pokus) 2. Databázi změn voleb mezi verzemi jádra (jinak se minulý .config i s uživatelskými vyjímkami nezkonvertuje na nový funkční .config)

Takže jsem navrhl systém (=soustava skriptů) pro konfiguraci a vzal jsem to od podlahy (=ideálně náhrada nconfig).

P.S. WTF? abíčko mi najednou v tomhle postu limituje délku příspěvku na cca 1024 znaků? (původně jsem teda myslel, že to je chyba v tagu a hledal binárním dělením).

[pavlix]

Tak ideální způsob instalace linuxu je obvykle použití distribučního jádra.

To pro mě v Gentoo bohužel neplatí, ledaže bys měl namysli distribuční jádro z jiné distribuce. Ale i tak se ti může stát, že nepovolili nějakou pro tebe důležitou volbu a právě proto jsem se vůbec začal zabývat možností zlaté střední cesty mezi použitím hotového jádra a sraním se s každou jednotlivou volbou, kdy bych si nastavil (a udržoval!) jenom ty volby, které chci skutečně změnit.

Ty navrhuješ, že přidáš něco jako use flagy a seznam závislostí do balíčkovacího systému a to tak, že to bude řídit konfiguraci kernelu a bude to statické.

Právě. Díváme se na problémy i možná řešení úplně jinak. Navíc si stále nejsem jistý, zda jsi mému návrhu porozuměl, když máš pořád potřebu kritizovat neúplnost toho řešení. Vzhledem k tomu, že poslední (a tím v podstatě hlavní) instancí konfigurace by byl uživatelský konfigurační soubor, považuju řešení za úplné. Účelem nebylo mít nástroj, který udělá konfiguraci za tebe, ale který ti s konfigurací maximálně pomůže a především je jeho činnost opakovatelná, což se o procházení menuconfigu říct nedá.

Můžeš se na to dívat i jinak. Do začátku by mi bohatě stačil třeba pythoní modul na konfiguraci jádra, který by uměl akce typu zapni modul i se závislostmi a já bych si za použití browseru voleb jádra a dokumentace k různým programům a software posbíral hrubý seznam toho, co chci povolit a průběžně ho doplňoval. Volání ve skriptu bych si rozdělil podle toho, zda jsou pro konkrétní hardware, software nebo vlastní volba, která do ničeho nezapadá.

Ale nejspíš by mě štvalo to takhle pořád upravovat, takže bych si samotné volby brzo vytáhnul do samostatných souborů v nějaké deklarativní syntaxi. V případě úspěchu u dalších uživatelů by pak šlo části odpovídající konkrétnímu hardware a software zveřejňovat na Gentoo Wiki, případně by se mohly začlenit některé soubory do balíčků a automaticky by se nad nimi spouštěla kontrola, zda jsou splněné, popřípadě by mohl genkernel umět příští konfiguraci jádra upravit tak, aby je splnil.

Hledat v tom cokoliv složitějšího je podle mě omyl.

[pc2005]

což se o procházení menuconfigu říct nedá

On ještě někdo používá menuconfig a ne nconfig? :-O

by uměl akce typu zapni modul i se závislostmi a já bych si za použití browseru voleb jádra a dokumentace k různým programům a software posbíral hrubý seznam toho, co chci povolit a průběžně ho doplňoval.

Ovšem je otázka, zda by se v tom uživatel neztratil. Ty závislosti nejsou jednoznačně definované (=depends on ...). Sice si zapneš usb dvb-t dongle, kterej ti zakompiluje usb a v4l subsystém, ale i tak to nebude fungovat, protože nebudeš mít vybranej usb řadič. To může u něčeho jako "pci řadič → usb řadič → i2c řadič → i2c čip" nastat skoro na všech úrovních.

[Michal Kubeček]

readv()/writew()

writev()

Jan Kara

Kára

[frr]

Koukám, že všechny tři citáty jsou z 1.4., ovšem Linusův citát je zřejmě vážně míněn, kdežto další dva budou odhadem aprílové.

[frr]

Sektor větší než 4k ? Přijde mi ta debata dost akademická.

4k je myslím velikost, která už není natolik malá, aby způsobovala zásadní režii (ono mezi námi 512B snad taky není zásadní problém), velké sekvenční přístupy na disk jsou beztak řešeny jako nějaká dávka s DMA přenosem, adresovaná na různých vrstvách "od-do", a samotná velikost datového typu pro LBA adresu ani reálná bitová hloubka adresy taky nejsou problém / neznamenají rozdíl. 4k vypadá jako konkrétní zajímavá velikost z toho důvodu, že přesně pasuje na běžnou velikost VM stránky. Menší sektory se musely shlukovat, případné větší sektory se budou muset drobit...

Z hlediska výkonu a průchodnosti mi jako mnohem častější praktický problém přijde "mnoho paralelních pomalých čtenářů/zapisovačů" nad točivými disky. Je to už pár let, co jsem se v tom vrtal, docela bych si s gustem přečetl nějakou aktuální analýzu, jak se s tím umí vypořádat dnešní linuxový kernel - VM a jeho WB cache, read-ahead, IO schedulery a dostupné souborové systémy. Ale to by problematiku musel někdo v kostce nastudovat, aby vůbec dokázal něco relevantního napsat... Pro tento problém má klasický tupý RAID zásadní nevýhody (degraduje disponibilní IOps). Libil by se mi souborový systém pro jeden stroj, který by běžel nad poolem fyzických disků, udržoval by každý soubor ve více kopiích na více discích, přitom by diskový prostor alokoval "po souborech" tak, aby jeden každý soubor byl na konkrétním disku pokud možno sekvenční, a aby umístění metadat vyžadovalo minimum seeků navíc na režii, aby OS bral maximální ohled na momentálně otevřené soubory (držel v keši payload i metadata)... a parametry jako velikost per-file read-aheadu, trpělivost write-backu, velikost RAM použitelné na cache, nebo povinnost bariér aby byly laditelné. V některých aspektech jdou správným směrem BTRFS a ZFS, ale ono kromě FS záleží taky na detailech implementace FS a dalších okolnostech v konkrétním OS

Jestli bude vespod velikost sektoru 512B, 4 kB nebo 64 kB je vcelku jedno.

[Atom321]

Velikost sektoru je daná fyzikou úložného média. Zapisuje a čte se vždy jako celek. Pokud tedy požadavek na zápis není zarovnaný na velikost sektoru, musí se sektor přečíst, část změnit a zase zapsat. Elektronika disku si to řeší sama, takže navenek se disk tváří jako by měl sektory 512B.

Pokud fyzická velikost přesně "pasuje" na logickou velikost sektoru v OS, je všechno mnohem jednodušší a rychlejší.

[j]

Viz Atom, vetsina SSD ma kuprikladu 64kB. Takze FS se stejnou velikosti sektoru redukujes likvidaci toho SSD, protoze se da spousta veci poresit vejs, a omezit prepisy/zvednout vykon.

Jinak pritomnost mnoha paralelnich ctecu/zapisovaci nad disky ... se resi uz leta ... dostatecnycm mnoztvim RAM. Mam tu trebas cca 200GB databazi ... na stroji se 128GB RAM. Disky se vicemene flakaji. Vse podstatne se vejde do pameti.

A mimochodem, jak si predstavujes ze RAID limintuje IO? Nejrychlejsi HDD neprekroci 200. R10 pri klasickym usporadani 2xN = Nx IOhdd na zapis + 2Nx IOhdd pro cteni. Na filesystemu prd zalezi, a na tom, jestli je nebo neni soubor ulozen sekvencne taky. Dost pochybuju, ze bys mel tolik disku kolik mas uzivatelu, aby to melo smysl resit.

[trekker.dk]

Na filesystemu prd zalezi, a na tom, jestli je nebo neni soubor ulozen sekvencne taky.

Jasně, protože soubor rozházený po celém disku se čte/zapisuje úplně stejně, jako když leží na jednom místě.

[pavlix]

A to při správné velikosti bloku neplatí?

[frr]

Ohledně SSD... u ATA/SATA Flash médií (uvnitř NAND), která prezentují LBA abstrakci, jsou dokonce tři patra adresace: navenek LBA přes 512B sektory, uvnitř úplně vespod erase bloky velké třeba 1-4 MB, mezi jsou ještě "řádky" nebo-li "stránky" zápisu/čtení, které jsou velké asi 1-4 kB. Minimální velikost čtení nebo zápisu je řádek=stránka, minimální velikost mazání je erase blok. Čili tady by se dala vést debata 1) co je optimální velikost bloku prezentovaného navenek (patrně řádek=stránka) a 2) jak optimálně řešit mapování LBA -> řádky -> erase bloky. Linux má filesystémy, které jsou optimalizované na životnost a výkon NAND Flash - ovšem podmínkou je, že má Linux flashové čipy přímo mapované do paměti. Přitom flashové disky, které slouží jako "náhrada velkých harddisků" v serverech apod., jsou tradičně obsluhovány nějakým SATA->Flash řadičem (uvnitř "disku"), který použití vymazleného flashového filesystému znemožní Reálně se flashové filesystémy jako JFFS2 používají pro onboard MTD = embedded bootovací disky maličkých zařízení (WiFi APčka, SoHo routery apod.) - velikost pár desítek MB.

Ano, přítomnost mnoha čtečů/zapisovačů na disky se řeší léta. A třeba Solaris na svém nativním ZFS to zřejmě už léta zvládá s noblesou, např. díky efektivnímu využití veliké RAM a bůhví čemu ještě. Linux to pár let zpátky neuměl. Nezáleželo na tom, kolik GB RAMky jste mu dal - při write-backu to prznil I/O scheduler (deadline scheduler na základě timeoutu pod zátěží relativně rychle degradoval do režimu FIFO) a read-ahead byl na blokové vrstvě, nikoli per flow, pak snad byl i per flow, ale nedal se "zvenčí" ladit, v omezené míře to mohla dělat aplikace nějakým ioctl() na otevřeném deskriptoru... Takže jste mohl mít RAMky, kolik jste chtěl, ale nedokázal jste Linux donutit, aby ji efektivně využíval.

Bavím se o ukládání a čtení velkých souborů skrz nějaký filesystém na disky. Databáze jsou odjakživa jiná píseň, DBMS tradičně zcela obcházejí filesystém a VM hostitelského OS a baví se nejraději přímo s disky v "direct" módu. Ale ukládejte soubory o průměrné velikosti několika set MB do relační databáze... databázoviny řeší velikost stránky 4 kB.

Ohledně RAIDů... tady mám takový graf závislosti IOps a MBps na velikosti transakce:

http://www.fccps.cz/download/adv/frr/hdd/perf_vs_tsize.gif

Pro maximální "výtěžnost" MBps z konkrétního disku je potřeba, aby při čtení pokud možno nemusel seekovat. Jako rozumná vychází velikost transakce řádově v megabajtech (minimálně cca 1 MB). Neznám mnoho RAIDů, které se dají přemluvit, aby použily stripe size 1 MB nebo víc. Umí (uměl) to softwarový MD RAID v Linuxu. Pokud čtete sekvenčně soubor z RAIDu, a soubor je na RAIDu sekvenčně alokovaný, a čtecí transakce vyžaduje načtení několika strajpů po sobě, tak to znamená, že musí několik disků prakticky současně seeknout na shodné místo - i v krásném případě RAID0, který se prakticky nepoužívá kvůli provozní stabilitě. To znamená "degradaci disponibilních IOps", o které jsem mluvil. Pro optimální využití IOps disků by bylo třeba, aby pro každou čtecí transakci musel jednou seeknout jeden disk. V RAIDu platí, že čím menší stripe size, tím menší transakce stačí, aby několik disků muselo seekovat synchronně. Zároveň pro optimální "paralelní sekvenční čtenáře" je třeba, aby fungoval inteligentní read-ahead o nějaké nezanedbatelné velikosti, aby se seekování disků dostalo do "sekvenční" oblasti křivky průchodnosti. Takže okamžitě narazíte na kolizi dvou požadavků: read-ahead nad 1 MB, lépe 4 MB nebo víc per disk (sekvenčně v souboru i na disku) a omezeni stripe size typicky na 512 kB max.

A navazuje další problém: aby souborový systém při sekvenčním čtení souboru nemusel seekovat "mimo sekvenci" pro načítání metadat. Struktura metadat např. ext2 a spol. je vysloveně rozdrobená, rozprostřená po ploše disku, navíc standardní velikost FS bloku v Unixu je 1 kB, block group má pár kB.

Nakonec možná líp by se chovaly FS z rodiny FAT (pro velké disky ExFAT) - zejm. při velké alokační jednotce (cluster o velikosti několika MB) by se metadata FAT vešla do RAM, čímž by odpadlo seekování "mimo sekvenci". To jsou ale paradoxy - FAT jako optimální FS

A zbavit se RAIDu = alokovat soubor spojitě v rámci jediného disku. A pokud to má mít redundanci, tak naalokovat jeden soubor víckrát na více discích.

Tu fintu s "jednotlivě mountovanými disky" nemám ze své hlavy, někteří lidé si na tom postavili úložiště "na koleně".

A stejným směrem míří i clusterové systémy pro ukládání souborů víckrát na více fyzických strojích, s lokálními FS. Opět hrozně starý nápad...

[Jendа]

Jinak pritomnost mnoha paralelnich ctecu/zapisovaci nad disky ... se resi uz leta ... dostatecnycm mnoztvim RAM. Mam tu trebas cca 200GB databazi ... na stroji se 128GB RAM.

OK, a když nemám dat 200 GB, ale několik TB? Takové úložiště vyjde dneska na pár korun, ale stroj s víc než 32 GB RAM už ne.

[ebik]

Jedno to není, protože pokud hardware načte vždy 128kb z důvodu, že je to výrazně jednodušší naimplementovat, tak OS který k němu bude přistupovat po 512B blocích, může nevhodným seřazením požadavků snížit výkon až 256x, a to už by bylo hodně znát. Tady se jedná právě o to, jak v OS zařídit aby četl po stejně velkých blocích jaho hardware a nezahazoval data, která HW stejně načetl.

[ebik]

Uch, ignorujte mne, měl jsem tu stránku načtenou od včerejška a neviděl zbytek diskuze.