Jaderné noviny – 23. 6. 2011: Uživatelsky přívětivá jména disků

5. 7. 2011 | Jirka Bourek | Jaderné noviny | 4263×

Aktuální verze jádra: 3.0-rc4. Citáty týdne: Dan Williams, Linus Walleij. Uživatelsky přívětivá jména disků.

Obsah

• Aktuální verze jádra: 3.0-rc4
• Citáty týdne: Dan Williams, Linus Walleij
• Uživatelsky přívětivá jména disků

Aktuální verze jádra: 3.0-rc4

Současné vývojové jádro je 3.0-rc4 vydané 20. června. Sestává se hlavně ze spousty oprav (některé pro významné výkonnostní regrese) a pár nových ovladačů. Také zjevně obsahuje novou chybu při překladu, která může vyžadovat aplikaci tohoto patche. Všechny detaily najdete v kompletním changelogu.

Stabilní aktualizace: tento týden žádné nevyšly.

Citáty týdne: Dan Williams, Linus Walleij

Kvůli hardware bych se často nejraději oblékl do černého, sedl si na konec baru, pil a plakal. Matthew Garrett je tam často hned vedle mě, takže mám aspoň na svém výletě do černého, černého zapomnění nějakou společnost.

-- Dan Williams

Protože jsem beznadějný optimista, rozhodl jsem se vyřešit veškeré ovládání pinů v tomto subsystému. Reklamní rap by byl nějak takhle:

• Potřebujete zvednout napětí na pinu na 3.3V pomocí 1MOhm odporu?
• Chcete pin multiplexovat kvůli různým funkcím?
• Chcete nastavit kapacitu pinu na 10pF?
• Chcete mít výstup s otevřeným kolektorem?
• Řídíte ve svém ASIC něco nebo všechno z výše zmíněného softwarem?
• Zoufáte si kvůli nedostatku relevantních frameworků?

NEZOUFEJTE! Subsystém pinctrl je zde a zachrání vás!

-- Linus Walleij

Uživatelsky přívětivá jména disků

napsal Jake Edge, 22. června 2011

Jména zařízení mohou hlavně u disků být pro správce matoucí, protože se při bootu přiřazují podle pořadí, v jakém jsou disky objeveny. Stejnému fyzickému disku může při každém bootu být přiřazeno jiné jméno zařízení (v /dev), což znamená, že zprávy v jaderném logu a výstup různých nástrojů nemusí odpovídat pohledu správce na systém. Nedávná sada patchů chce tuto situaci změnit, ale naráží na odpor jaderných vývojářů, kteří si myslí, že by se to mělo řešit v uživatelském prostoru.

Patche zaslal Nao Nishijima a jsou relativně přímočaré. Do struct device prostě přidávají záznam preferred_name, které lze nastavit pomocí sysfs. Patche potom mění zprávy v logu o SCSI a výstup /proc/partitions tak, aby se preferované jméno použilo, když bylo nastaveno. Greg Kroah-Hartman tady zmínil obavu ze změny /proc/partitions, protože různé nástroje tento soubor analyzují a ten je tedy součástí jaderného rozhraní do uživatelského prostoru. Přidání preferovaného jména na každou řádku by tyto nástroje snadno mohlo zmást.

Co je ale důležitější, poznamenává Greg, bylo by jednoduše možné změnit tyto nástroje tak, aby ve svém výstupu tato jména použily samy. Jakékoliv schéma, které by mapovalo preferované jméno na specifický disk, vyžaduje nějaký soubor s mapováními; pokud tedy nějaký nástroj (mount, smartd a další) chce použít tato preferovaná jména, může daný soubor s mapováním použít úplně bez účasti jádra:

Vážně, to už mohlo být hotové, poprvé se to diskutovalo před rokem. Všechna distra již teď mohla mít aktualizované balíky a nebyl by to žádný problém.

Stále si myslím, že správný způsob, jak tento problém řešit, je v uživatelském prostoru, ne v jádře.

I když patche používají preferred_name jenom pro disky, cílem je umožnit je přidat k jakémukoliv zařízení (a pak změnit zprávy v logu a nástroje tak, aby se používala). Jsou modelovány podle záznamu ifalias, který byl roku 2008 přidán k síťovým zařízením, ale někteří tohle nepovažují za něco, co by se mělo napodobovat. Umožnit přiřadit síťovému zařízení jenom jeden alias obecně není dostatečné, protože lidé obvykle nechtějí jenom jedno, ale několik jmen naráz, řekl Kay Sievers; ifalias se tedy používá jenom v několika SNMP nástrojích. V současnosti udev udržuje sadu odkazů v /dev/disk/by-*, která spojují disky a jaderná zařízení podle různých charakteristik (ID, jméno [label], cesta a UUID). James Bottomley by rád viděl, kdyby se o preferovaná jména rozšířilo tohle:

O veškeré pojmenování pro uživatelský prostor bude postaráno pomocí obvyklých pravidel v udev, takže by pro disky bylo něco jako /dev/disk/by-preferred/<fred> obyčejným symbolickým odkazem.

Tím se zajistí, že výstup jádra a vstup udevu bude konzistentní. Stále to bude vyžadovat, aby nástroje v uživatelském prostoru, které jména odvozují ze zařízení, byly modifikovány a vypisovaly preferované jméno.

Tento návrh má ale problémy. Aby udev zjistil, že bylo nastaveno preferované jméno, musel by se vygenerovat uevent. To by šlo zařídit, ale jak upozornil Kay, vede to k dalším problémům. (Kay místo by-preffered používá by-pretty):

Co by se stalo, kdybychom připojili:

/dev/disk/by-pretty/foo

a pak by si nějaký nástroj pomyslel, že hezké jméno by mělo být „bar“, zapsal by ho do /sys, my bychom dostali uevent, starý link zmizí, dostaneme nový a mount najednou nemá pro připojené zařízení uzel zařízení [device node].

Kay řekl, že udev sleduje zařízení připojená k systému (a jejich atributy jako, potenciálně, preferované jméno), ale neobsahuje žádný koncept sledování jmen, která již neplatí. To znamená, že udev nemůže jenom tak nechat staré záznamy být, když uživatelský prostor změní preferované jméno: Nemůžeme jenom tak do /dev přidávat věci, které nemají záznam v databázi udevu, při odpojení zařízení by se nikdy neodstranily a nechávalo by to po sobě pořádný nepořádek.

Jedním možným řešením problému s přejmenováním by bylo umožnit do preferred_name jeden zápis, takže jakmile by byl alias jednou nastaven, nebylo by ho možné měnit bez rebootu. udev by mohl nastavit správné odkazy a různé nástroje by mohly aliasy používat podle potřeby. To by vyřešilo problém s přejmenováním za cenu flexibility. Obecně nikdo nebyl proti nápadu přidat diskům snáze zapamatovatelná jména, jedná se spíše o otázku, jak se k nim dostat.

Kay navrhl přidat do udevu způsob, jak vypsat všechny symbolické odkazy, které vytváří během objevování zařízení. Každý (nebo každý nástroj), kdo by potřeboval spojit alias s konkrétním diskem, by tento výstup mohl použít, zjistit, o které zařízení se právě jedná (například podle UUID), a nastavit alias podle potřeby. To by obecně fungovalo, ale James Bottomley to považuje za zbytečně složité pro uživatele:

Nicméně i když budeme předpokládat, že si vyberou jedno ze současných jmen, stále budou muset mapování nastavit manuálně; i když budou mít všechny informace, nemůžou jednoduše něco zkopírovat z dmesgu, budou to muset zkopírovat, upravit, aby se přidalo preferované jméno, a pak vložit... to je pro většinu uživatelů příliš otravné. Souhlasím s tím, že všechny rozumné nástroje lze upravit automaticky, ale muset upravit řekněme cat, aby fungovalo i cat /proc/partitions, by v upstreamu nebylo akceptovatelné

Důvodem pro to uložit to v jádře je, že je to prostě jednodušší než snažit se změnit všechny nástroje a řeší to 90% problému. Je to tedy použitelné řešení, i kdybychom potom museli upravovat i nástroje, abychom se dostali ke 100%.

Kay a správce jádra ovladačů Greg Kroah-Hartman to považují za zakrývání mnohem důležitějších záležitostí. Kay by přinejmenším rád viděl, kdyby se ladící a chybová hlášení ve stylu textového souboru nahradila (nebo doplnila) něčím strukturovanějším:

Potřebujeme chytřejší uživatelský prostor s kanálem z jádra do uživatelského prostoru pro ladící/chybová hlášení, ze kterého budou padat strukturovaná data. Uživatelský prostor musí tato data indexovat a začlenit do nich spoustu informací z uživatelského prostoru.

Když se do jádra přidá další jméno, bude hloupý textový výstup z printk() o něco čitelnější, ale stále to nezní jako řešení. Nablýskat syslog není řešením a nelze to vyřešit v jádře samotném.

Z pohledu uživatele nicméně disky již nyní mohou mít jména (například označení na pouzdře) a bylo by poměrně vhodné, kdyby je jaderná hlášení používala. Nakonec Kay není proti řešení specifickému pro disky (ne pro všechna zařízení), ale myslí si, že to opravdu není správná cesta. Greg souhlasí a trvá na tom, že tahle změna se do jádra ovladačů nedostane. Vzhledem k tomu Nao plánuje patche přepracovat, přesunout jméno do struct gendisk, přejmenovat pole na alias_name (místo „preferred“), aby se lépe vystihl jeho účel, a generovat uevent, když se jméno změní.

Podle příkladu síťových ifalias se do rozhraní mezi jádrem a uživatelským prostorem přidává další věc, tentokrát pro disky. I když to možná vyřeší aktuální problém správců, také to po sobě zanechá nějaký kód, až nebo pokud se najde lepší řešení. To je nešťastné, ale vzhledem k tomu, že se zde jedná o skutečný problém, změna je omezena na subsystém, jehož správce (James Bottomley) s ní souhlasí, pravděpodobně se v jádře objeví zanedlouho. Jakákoliv změna logování ladících hlášení a chyb podle toho, co popsal Kay, je rozhodně ještě daleko, nicméně po strukturovaném výstupu z jádra se volá již dlouho. Někdy je prostě jednodušší udělat takovou změnu na jednom místě místo toho snažit se identifikovat a opravit všechna místa mimo jádro, která by ji mohla potřebovat.

       

Komentáře

[Bedňa]

Môhol by toto niekto viac osvetliť?

Stejnému fyzickému disku může při každém bootu být přiřazeno jiné jméno zařízení (v /dev), což znamená, že zprávy v jaderném logu a výstup různých nástrojů nemusí odpovídat pohledu správce na systém.

[graviton]

Stejnému fyzickému disku může při každém bootu být přiřazeno jiné jméno zařízení (v /dev)

Například pokud jsou v systému namíchaná ata a sata zařízení, jádro je při každém bootu uvidí v jiném pořadí a přidělí jim jiné názvy zařízení (sda, sdb a tak..). Čili správce se musí řídit něčím jiným než kernelími názvy zařízení, jinak nenapíše ani fstab.

což znamená, že zprávy v jaderném logu a výstup různých nástrojů nemusí odpovídat pohledu správce na systém.

Pohled správce na systém:

LABEL=data11    /cache          ext4    defaults,noatime        0       2

Kernelí hláška:

EXT4-fs (sdb3): mounted filesystem with writeback data mode. Opts: (null)

Fakt nevím co zrovna dnes je sdb3 a pokud bych tu hlášku chtěl luštit, musel bych jít a zjistit to.

[Bedňa]

FStab píšem podľa UUID, ale to že jadro ide na náhodu som netušil. To keď budem mať dva bútovateľné disky, tak je na náhodu ktorý nabútuje?

[graviton]

Bios nabootuje z prvního použitelného, který má nastavený. Pořadí se šteluje v biosu (asi záleží na biosu, ale doufejme že to není náhodné). Grub bere to z čeho mu bootuje bios jako hd0, stále žádná náhoda. Root fs už je potřeba uvést něčím stabilním, např. UUID, jinak tam jádro skutečně začne vyrábět náhodu.

[Bedňa]

Zraná mi to nejak nepálilo, ale už odpaľuje :) Dík.

[petr_p]

Root fs už je potřeba uvést něčím stabilním, např. UUID, např. UUID, jinak tam jádro skutečně začne vyrábět náhodu.

Přesněji řečeno jádro žádné UUID nezná. To je výmysl udevu a tudíž ve skutečnosti parametr root zpracuje skript z initramdisku, UUID přeloží na skutečný název zařízení (například /dev/sdb3), a tento dá připojit. Jinak řečeno UUID a podobné jsou záležitost čistě uživatelského prostoru, jádro o tom nemá nejmenší tušení (jinak by muselo při každém mount(2) zkoumat obsah všech blokových zařízení).

[Josef Kufner]

I to se může stát. Jeden server mi takle bootuje pokaždé z jiného disku, takže mám grub na všech (a ten už to naštěstí trefí pokaždé).

[skolak]

Jirko Bourku, následující překlad je špatně: Chcete nastavit kapacitanci pinu na 10pF?

Ježišmarijá...

Kapacitance je zdánlivý odpor součástky, jednotkou je tedy Ω.

Pokud v anglickém originálu uvedli jako jednotku pF, určitě nejde o kapacitanci ale o kapacitu. Rychle to oprav.

[contyk]

Do you want to set the load capacitance of your pin to 10pF?

Je to jen o prekladu.

[finn]

Tak, a teď klikni v levém sloupci na odkaz vedoucí na české stránky — dostaneš se sem.

[contyk]

A to je prave ta pointa.

[Luboš Doležel (Doli)]

Že mají na Wikipedii blbě přesměry nic neznamená...

[loki]

+1, uplne to bije do oci

[David Watzke]

Díky, opraveno.

[android]

Čéče, Davide, ty seš teď redaktor, že opravuješ články? Tak to gratuluju...

[David Watzke]

Nejsem redaktor, ale mám teď administrátorský práva už ke všemu.

[Luboš Doležel (Doli)]

Abych nemusel všechno opravovat z Itálie

[Sten]

David je redaktor, ale AbcLinuxu o tom ještě neví

[trekker.dk]

Kapacitance je zdánlivý odpor součástky, jednotkou je tedy Ω.

Ano, toho jsem si vědom. Nicméně v anglickém originálu je taky capacitance a nikoliv capacity

[pc2005]

No pokud na tý nožičce bude ten kondík a třeba hodiny, tak tam bude i ta kapacitance (zvlášt v mixu s tím 1M odporem to bude zajímavý).

[Michal Kubeček]

Ale těžko bude 10 pF… :-)

[pc2005]

Jj.

[stativ]

Možná jsem to vůbec nepochopil, ale co je za problém na tom používat /dev/disk/by-label?

[kralyk z abclinuxu]

+1, a krom toho tu je ještě udev, že, případně přinejhorším LVM. Fakt nevim, co řešej.

[pavlix]

Já používám LVM už jen proto, abych ty ostatní výmysly nemusel řešit. Akorát Fedoru holt musím dodnes (13, 14 i 15 pokud vím vznikly v době kdy to Debian stable už uměl) instalovat s bootovacím filesystémem na flashce, který až za běhu přesunu do LVM a upgraduju na Grub2.

[Sten]

Nejde o labely v user space (/dev), ale o hlášky v dmesg. Labely by se sice daly používat i tam, ale ty nemají zaručenu jednoznačnost a to by se muselo nějak řešit. Navíc třeba celý disk nelze olabelovat, labelovat lze jenom souborové systémy.

[misacek]

Možná bude znít můj příspěvek neznale, až amatérsky, protože do jádra nějak víc nevidím, ale... Pokud vezmu v potaz, že tu máme BIOS od toho, aby v průběhu POSTu prozkoumal včetně dalších věcí taky připojené disky a další úložiště, načež očekávám, že si je musí nějakým způsobem pamatovat a podle něčeho pokračovat k bootstrappingu, jakým zatraceným způsobem může jádro hrát na nějakou "náhodu" a koukat si po discích jak mu to zrovna přijde pod ruku? Očekával bych, že na tohle (rozumnějme například přejímání informací o úložištích z BIOSu) má jádro nějaká pravidla, stejně jako ujasnění, jak se vypořádává s umístěním disků na IDE kanálech, SATA rozhraní podle čísel, prioritu SATA před PATA a podobně... Kde tedy udělali chybu? Nebo jsem jenom přespříliš naivní, neznalý?

[Max]

Dřív to bylo tak, že si každé jádro dělalo, co chtělo. Jednou se PATA disk tvářil jako hdX, podruhé jako sdX atd. Tzn, že člověk upgradnul systém, tím i jádro a najednou byl root=/dev/hda1 špatně, protože hda neexistovalo, zato existovalo sda. Pak se to tak nějak dalo dokupy a nyní se SATA disky hlásí jako sdX a PATA disky jako hdX.
Ovšem i toto je trochu nevyhovující. Tyto názvy se odvíjejí z pořadí na kšandách, z toho, jak to prezentuje bios atd. To není moc pěkná věc. Pěkná věc je mít systém na nějakém disku, na nějaké partition a úspěšně s ním nabootovat kdekoliv.
V současné době se toto částečně řeší pomocí LABEL(filesystém), nebo pomocí UUID(partition/filesystem). Navíc LABEL není unikátní. Když si pomocí label mountuješ oddíl a pak ti někdo přijde s diskem (nebo flashkou), který má stejný label a strčíš ho do PC, tak se ti to asi nebude moc líbit.
Taktéž se ti moc nemusí líbit přehazování disků na kšandách. Jednou by jsi měl systém na sda, podruhé na sdb atd.
Tato problematika je trochu obsáhlejší a mohl bych uvést i další příklady kolízí a problémů s tím spjatých, nicméně jako ukázka je to myslím dostačující.
Zdar Max

[misacek]

Jasně, tomuhle všemu tak nějak rozumím... Asi jsem to napsal zase až moc jednoduše :) BTW, /dev/hdX naming už snad dnes nepotkáš, ne? To se někdy v historii (v prazvláštní jednotce času, 2 nebo 3 vydání Debianu :) zpátky) zahodilo. Samozřejmě ta "nepěknost" z pohledu portable bootovatelnosti je očividná, ale zaskočil mě už ten úvod kapitoly, který chvíli skoro vyzněl, jakoby v tom nebyl řád ani v případě, že neměníme konfiguraci systému (čili nečachrujem s disky uvnitř), načež jsem si musel nahlas říct "cože?". Když už bysme chtěli sahat až takhle vysoko, nabízí se docela elegantní řešení - přijít s něčím, jako UUID zařízení, který by zařazování v /dev v závislosti na pořadích úplně vymýtilo. K tomu by měl možná ten patch s pojmenováním zařízení blízko jako jeden celek dohromady.

Jinak z pohledu systému to člověku snad zase tolik život nekomplikuje (pominu teď situaci, když má někdo nutkání bootladerem obsluhovat více disků, tam by mohl přijít problém, nebo si často hrál s pořadím disků ve stanici) - všechno níž už docela dobře dokáže zpracovat bootloader a jádro s pomocí udev-u a statického mountování s pomocí UUID, díkybohu za to. Že by to zrovna dvakrát nefungovalo s čímkoliv neunikátním, ex když si to může přizpůsobovat uživatel, je jasná věc :)

[petr_p]

Zrovna dneska jsem upgradoval v serveru jádro na 2.6.39.2 a co myslíš? Mám ho tam. IDE subsystém s hd* názvy.

V jádře si stále můžeš vybrat mezi IDE a ATA. Kde si ale už nevybereš, je udev, který od jisté verze IDE názvosloví nepodporuje.

A zrovna v tom stroji mám více disků. A jako na potvoru taky kopii souborového systému, protože jeden z disků se začal poroučet. Takže třeba tady LABEL nepomůže, protože tam jsou dva systémy s touže jmenovkou (a obecně LVM snímky jich takových mohou navyrábět mnoho).

Takže začínám zkoumat, jestli initramdisk bude nebo nebude potřeba, jestli subsystém ATA dokáže nebo nedokáže na IDE hardwaru držet stabilní číslování podle topologie nebo ne.

[j]

Pravdepodobne (na 99,999%) jen proto, ze mas v kernelu absolentni driver pro pata radice. Kdyz ho vyhodis, tak budou vsechny disky sdX.

[XjCook]

jj, v Arch kerneli určite je len /dev/sdX

[j]

BTW: Bios se uz peknych par patku prakticky vubec nepouziva, je tudiz uplne sumafuk zda disky (nebo cokoli jinyho) bios vidi nebo nevidi.

[Max]

Tak nakonec jsem si to ověřil a je to skutečně ok. Grub bere bootovací disk jako hd0 a o zbytek se postará UUID, takže přenositelnost by neměl být problém (ze stroje do stroje, zpřeházení na kšandách atd.).
Zdar Max

[pavlix]

Navíc Grub2 pokud vím umí podle těch UUID hledat. A určitě umí hledat FS podle souborů.

[Kvakor]

Očekával bych, že na tohle (rozumnějme například přejímání informací o úložištích z BIOSu) má jádro nějaká pravidla, stejně jako ujasnění, jak se vypořádává s umístěním disků na IDE kanálech, SATA rozhraní podle čísel, prioritu SATA před PATA a podobně... Kde tedy udělali chybu? Nebo jsem jenom přespříliš naivní, neznalý?

Pokud vím, tak jádro přiděluje jména SCSI diskům tak, jak se detekují, a to nejen "krátká jména" (sda, sdb ...), ale i ta dlouhá SCSIcky sběrnicoidní (dev:bus:target:lun), protože i jednotlivé řadiče se mohou nadetekovat v různém pořadí.

Já osobně už jsem několikrát viděl, jak se uspaný disk odmítl včas probrat (hlásil "link is slow to respond, please be patient") a byl v důsledku toho přejmenován, protože ho disk, který se za běžných okolnosti detekoval jako poslední (je to PATA disk, přípojený na přídfavném řadiči od Promise), předstihl a detekoval se dříve.

[Michal Kubeček]

Očekával bych, že na tohle (rozumnějme například přejímání informací o úložištích z BIOSu) má jádro nějaká pravidla, stejně jako ujasnění, jak se vypořádává s umístěním disků na IDE kanálech, SATA rozhraní podle čísel, prioritu SATA před PATA a podobně...

Takové stálé a neměnné pořadí by sice bylo fajn, ale v plné obecnosti ho ani zajistit nejde. A i kdyby šlo, stejně by čas od času nastala situace, kdy se nějaké zařízení v důsledku chyby (ať už softwarové nebo hardwarové) nepodaří inicializovat a všechna další se posunou. Takže je lepší nepředstírat, že je možné persistenci pořadí zajistit.

[pc2005]

Tak mě napadá, že by bylo někdy dobrý, kdyby měl každej kus hw (i třeba pci karty, usb dongly) jednoznačnou identifikaci.

[Michal Kubeček]

To by sice pomohlo, ale pořád zůstává problém se situací, kdy se některé zařízení z jakéhokoli důvodu inicializovat nepodaří. Tedy pokud pro jména zařízení nepoužijete přímo ty unikátní identifikátory, ale to povede na podobně ošklivá jména jako s udev a by-id.

[Bedňa]

Dík za osvetlenie problematiky.