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

[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.