Portál AbcLinuxu, 7. května 2025 14:49
4.12.2008 16:32
kozzi | skóre: 55
| blog: vse_o_vsem
| Pacman (Bratrušov)
se mi zdá že je hned na začátku chyba ve verzi aktuálního jádra 
4.12.2008 16:53
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
Kde najdu anglický originál? Nikde ho nemůžu najít.
To OSD me desi. Je to cisty marketing, zadnou realnou vyhodu to podle me neprinasi. Zkratka, je to blbost.
I kdybychom pripustili, ze firmware bude otevreny, k cemu to podle vas bude dobre? Bude to jen dalsi vrstva navic, ktera se bude muset konfigurovat, a ktera bude zdrojem nekompatibility. Takhle si nainstaluji Linux a vim, ze vevnitr jadra je vsechno kompatibilni. S OSD budeme resit, zda je dotycny firmware kompatibilni s prislusnou verzi operacniho systemu atd. Jak pak asi ten disk prenesu nekam jinam, kdyz kazdy system bude pozadovat jiny firmware disku?
Bude to jen dalsi vrstva navic, ktera se bude muset konfigurovat, a ktera bude zdrojem nekompatibility.Jaký nekompatibility? To rozhraní je jasně stanovené a zdrojem nekompatibility bude akorát v případě, že výrobce standard poruší (akorát v takovém případě jeho zařízení dost pravděpodobně nebude fungovat dobře a lidi si ho nebudou kupovat.) A s konfigurací to pravděpodobně bude podobné jako u ostatních disků.
S OSD budeme resit, zda je dotycny firmware kompatibilni s prislusnou verzi operacniho systemu atdStandard je jeden, tak jaká kompatibilita s příslušnou verzí?
Jak pak asi ten disk prenesu nekam jinam, kdyz kazdy system bude pozadovat jiny firmware disku?To je jako kdybys řekl, že SCSI disk nemůžeš nikam přenést, protože systém bude požadovat jiný firmware disku.
> Standard je jeden, tak jaká kompatibilita s příslušnou verzí?
Dobry vtip. Viz treba ACPI. V okamziku, kdy je rozhrani dostatecne slozite, tak zajistit rozumnou kompatibilitu mezi nezavislymi produkty, zvlaste pak v asymtericke situaci, je dost problem.
Protoze jsou jednoduche a slozite veci. SATA ci SCSI v zakladni variante je relativne jednoduche (ve srovnani treba s ACPI), proto neni takovy problem, aby to fungovalo. Pokud je protokol jednoduchy a vsichni ho pouzivaji tim spravnym zpusobem, tak spis problemy nenastanou. Pokud je protokol bohaty a nabizi cetne moznosti, tim spis to fungovat nebude a bude treba resit kompatibilitu. Pripadne bude trvat leta, nez se vychytaji problemy.
Pokud je protokol jednoduchy a vsichni ho pouzivaji tim spravnym zpusobem, tak spis problemy nenastanou. Pokud je protokol bohaty a nabizi cetne moznosti, tim spis to fungovat nebude a bude treba resit kompatibilitu.Já osobně si myslím, že problémy vznikají jenom tam, kde vznik problému neznamená pokles obratu výrobce.
Vyhoda OSD by mohla byt v prenositelnosti dat mezi platformami. Mohla. Teoreticky.
Jenze ja mluvil o situaci, kdy bude ten firmware otevreny a kazdy si ho bude moci menit podle sveho (coz jste predtim povazoval za zadouci). Pokud je uzavreny, jako treba u SCSI, tak moje namitka pada (ovsem soucasne nastupuji ty predtim).
Navic, jak rika Ondrej - SCSI je patrne pomerne jednoduche rozhrani ridici se cisly bloku. Tady maji byt nejake tokeny, sifrovani a ja nevim co jeste. Ten standard se bude vyvijet a menit, a nekompatibility tedy zakonite vzniknou.
A jeste jste mi neodpovedel na otazku, v cem vlastne spatrujete vyhody OSD?
Jenze ja mluvil o situaci, kdy bude ten firmware otevreny a kazdy si ho bude moci menit podle sveho (coz jste predtim povazoval za zadouci).Tak pozor - otevřený firmware, který si každý bude moci měnit podle svého, a dodržení protokolu jsou dvě různě věci. Pokud to převedu na současnou situaci, tak protokol je, že programy volají funkce jako je
open(), fread() a je jim jedno, jak to vypadá pod nimi, jestli jádro naváže síťové spojení s NFS serverem nebo začne číst z diskety. Implementace ext3 se může třikrát změnit, ale programu to bude jedno, protože open() stále bude otevírat soubor.
Stejně tak u OSD se může firmware měnit tím způsobem, že se například změní rozložení bloků souborů na disku, protože se ukáže, že novější varianta je efektivnější. V podstatě se může změnit cokoliv, co se v současných jádrech mění u souborových systémů. Podstatné je, že navenek ten firmware na požadavek na čtení souboru číslo 12345 vždy odpoví čtením souboru číslo 12345.
A jeste jste mi neodpovedel na otazku, v cem vlastne spatrujete vyhody OSD?Při dobré implementaci to znamená snížení zátěže hostitelského systému. V podstatě by šlo o akcelerátor diskových operací, kdy by se jádro nemuselo zabývat rozložením souborů na disku tak, jak to dělá dnes. Když se to vezme kolem a kolem, tak jednoduchá implementace by mohla být taková, že by na tom disku v podstatě klidně mohl být nějaký současný Linux - ten by se staral o ukládání dat třeba na ext4 a hostitelskému systému by poskytoval rozhraní OSD disku.
Ale do RAIDu už to asi nedám.
Myslím, že výhodné to může být u malých zařízení, jako jsou MP3playery či fotoaparáty, protože nebude třeba implementovat FS driver. Ale u osobních počítačů to moc určitě úspor výkonu nepřinese, ale přinese to určitě problémy s RAID a kompatibilitou a variabilitou.
8.12.2008 18:57
Stanislav Brabec | skóre: 45
| Praha
Návrh existuje právě proto, aby vyšší výkon přinesl. Dnešní operační systém vůbec netuší, kde jsou sektory fyzicky uloženy, takže nedokáže dělat vůbec žádné optimalizace s výjimkou jediné: "Sektory bezprostředně za sebou = rychlejší operace". Naproti tomu OSD by byl fyzicky vázán k disku a znal by jeho strukturu. To může přinést významný nárůst výkonu jak u rotujících, tak u flash disků.
A co víc: ESD by mohl měnit fyzickou strukturu dat v závislosti na typu zapisovaných dat. Například při zapisu video streamu by mohl nepřerušeně zapisovat do sektorů o délce celé stopy, při práci s fragmentovanými daty by je dokázal efektivněji uložit pro náhodný přístup.
RAID by s ESD zcela změnil implementaci. Zatímco dnes se ukládají sektory a kontrolní bloky, ESD RAID řadič by distribuoval objekty nebo kontrolní objekty, zatímco na vstupu by přijímal ESD objekty od OS.
To bych stále považoval za lepší, kdyby zařízení o sobě umělo říct první poslední, než tohle.
10.12.2008 13:15
Stanislav Brabec | skóre: 45
| Praha
To by vyžadovalo mnohem vyšší komplexitu OS. Zde jsou příklady z možných vstupů pro optimalizaci:
Nyní si představte, že nový fiktivní standard DiskDescription verze 1.0 vytvoří infrastrukturu, která to vše zvládne. Pak přijde další výrobce, který nabídne disk s nezávislým vystavováním hlaviček na plotnách, se dvěma hlavičkami nebo s možností paralelního čtení ze všech ploten, nebo třeba hybridní disk, který má nejčastěji čtená data ve flash paměti. DiskDescription verze 1.0 k popisu nebude stačit, a k podpoře nového zařízení bude potřeba aktualizovat všechny OS na DiskDescription verze 1.1, nebo se vrátit k neefektivnímu nepřůhlednému LBA režimu.
Pokud chcete mit jednoduchy OS, tak proste pouzijete cisla bloku a na rychlosti se vykaslete. Pokud chcete mit rychly pristup na disk optimalizovany podle organizace disku, pak dejte OS vsechny informace, a ten uz si to zaridi. Ale firmware disku neni od toho, aby resil specificke potreby jednotlivych aplikaci - od toho je OS, ktery se da snadno zmenit.
Naopak firmware ma resit specificky system rozlozeni na disku, a poskytovat rozhrani, ktere je co mozna nejrychlejsi a pritom jednoduche. Coz cisla bloku splnuji docela dobre (proto jsme na ne take presli od cylindru/sektoru/hlav, vzpominate?).
Vas priklad je zavadejici. Pokud se napriklad ve vasi aplikaci nespokojite s tim, ze za sebou jdouci bloky mohou skoncit na ruznych cylindrech (a budete chtit za sebou jdouci bloky s co mozna nejrychlejsim pristupem), budete muset zacit fyzickou vrstvu resit pres nejake vhodne rozhrani. Neni jina moznost. Ale OSD takove rozhrani neni - z toho, co jsem videl na tech strankach, mi nepripada, ze by v takovem pripade nejak pomohlo. Naopak se spis snazi delat veci, ktere by mel delat OS (jako sifrovani, partitioning, metadata).
10.12.2008 15:28
Stanislav Brabec | skóre: 45
| Praha
„Všechny informace o hardwaru“ je velmi povrchní pojem. Aby to fungovalo, musela by existovat rozsáhlá a komplexní norma, která by popisovala vlastnosti všech představitelných zařízení pro ukládání dat, a stejně komplikovaná implementace v OS. A přesto by se časem objevilo zařízení, na jehož popis nestačí.
Systém cylindrů/sektorů/hlav byl kdysi lepši než LBA. K systému LBA v kombinaci s falešnými cylindry/sektory/hlavami se přešlo kvůli omezením MS-DOSu. Systém, kdy OS a sběrnice používají LBA, HDD vnitřně používá fyzické sektory (nerovnoměrně rozmístěné po disku), a BIOS a tabulka partition používá (na BIOSu základní desky závislý) systém falešných rovnoměrně rozmístěných cylindrů/sektorů/hlav není ani rychlý, ani přímočarý. Oddíl tak třeba fyzicky začíná uprostřed stopy a nejrychleji se čte spolu s koncem předchozího oddílu.
Již dnes prostý systém LBA přestává stačit. Například nesmírně komplikuje implementaci zápisových bariér. Vysoce bezpečný FS musí zapsat žurnál, poté metadata a data, a nakonec vymazat žurnál. Fyzický zápis na plotny musí být proveden přesně v tomto pořadí, nestačí pouze odeslání do vyrovnávací paměti HDD. Často je jedinou cestou čekání na kompletní vyprázdnění vnitřni vyrovnávací paměti HDD, kdykoliv OS narazí na bariéru.
Přesun metadat do nižší vrstvy je logický krok. Hardware má k dispozici více informací o povaze zapisovaných dat (velké bloky, malé bloky, metadata) a může provádět daleko lepší optimalizaci.
Při dobré implementaci to znamená snížení zátěže hostitelského systému. V podstatě by šlo o akcelerátor diskových operací, kdy by se jádro nemuselo zabývat rozložením souborů na disku tak, jak to dělá dnes. Když se to vezme kolem a kolem, tak jednoduchá implementace by mohla být taková, že by na tom disku v podstatě klidně mohl být nějaký současný Linux - ten by se staral o ukládání dat třeba na ext4 a hostitelskému systému by poskytoval rozhraní OSD disku.
Akcelerator ma smysl tam, kde je jasne, ze problemu napomuze jine hardwarove usporadani nez pouzivaji soucasne procesory (tj. napriklad u grafiky, kde se pouzivaji vektorove/stream procesory, nebo u sifrovani apod.). V ostatnich pripadech je uzitecnejsi proste pridat dalsi obecny procesor, protoze softwarove reseni je nejenom praktictejsi, ale muzete ten procesor vyuzit i pro jine ucely nez I/O.
Je pravda, že ten procesor tam asi bude dost stejný, nicméně možná by se dalo právě tím že se dá jinam odlehčit některým sběrnicím, které jsou nyní úzkým hrdlem mnohem více než rychlost a množství procesorů. Ale spíš to asi nemá smysl.
Co ty no-opy ? To mam chapat jako instrukci NOP ?
9.12.2008 21:27
mov r0, r0, či niečo podobné).
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.