Hardwarové novinky – 52+53/2009 (diskuse)

[Jardík]

V Linuxu nás to na 99,99 % nebude muset trápit, nepochybuji, že stejně jako v případě USB 3.0, bude první (nebo jedním z prvních) s podporou ADF

Článek na diit zmiňuje, že Windows Vista/7 s tím počítá, takže linux první nebude ...

[David Ježek]

no proto je tam ta závorka. nepodařilo se mi to nijak vypátrat, jak to s tou časovou posloupností bylo/je/bude.

[Jardík]

No jo, závorka, já jí přehlédl Taky věřím, že bude např. dřív než v MacOS X, který dodnes neumí ISO Level 3.

[the.max]

To, ze s tim pocita jeste neznamena, ze to i funguje

[petr_p]

Nevím, jak je na tom jádro, ale balík util-linux-ng (od 2.17rc2) je již připraven:

#: fdisk/fdisk.c:780
#, c-format
msgid ""
"\n"
"The device presents a logical sector size that is smaller than\n"
"the physical sector size. Aligning to a physical sector boundary\n"
"is recommended, or performance may be impacted.\n"
"\n"

Podobně blockdev má už nějakou dobu přepínač get sector size a naposledy byl rozdvojen na get logical block (sector) size a get physical block (sector) size.

Spolu tím začal blockdev i fdisk hovořit o tzv. alignment a že

#: fdisk/fdisk.c:792
#, c-format
msgid ""
"WARNING: The device does not provide compensation (alignment_offset)\n"
"for DOS-compatible partitioning, but DOS-compatible mode is enabled.\n"
"Use command 'c' to switch-off DOS mode.\n"
"\n"

Takže to je asi ona podpora zpětné kompatibility ze strany disků.

[Jan Grmela]

Ehm...

[Jardík]

Na to nepůjdu, bych se tam asi hned udělal a v kině se spoustou diváků by to nebylo moc příjemné, ať už pro mě nebo pro ně

[frr]

Heh - čili ADF víceméně znamená, že disk bude interně používat a navenek hlásit velikost sektoru 4 kB (jenom doufám, že disk tohle skrz ATA hlásí / OS to detekuje - no asi jo, třeba CD média mají taky sektor tuším 2 kB, ale zas ATAPI je něco trochu jiného než ATA). Na SCSI příležitostně používám 4kB sektory už delší dobu, u externích RAIDů (je to konfigurovatelné).

Widle s tím nikdy neměly problém (počínaje Windows 2000) a jedná se o klasický způsob, jak ve Windows 2000 / XP 32bit dosáhnout velikosti disku nad 2 TB (protože limit na 2^32 sektorů = 32bitovou LBA adresu nelze v těchto OS obejít). Jde o to, že OS interně softwarově používá pro LBA adresy v blokové vrstvě 32b datový typ.

Druhou možností, jak připojit k počítači disk větší než 2 TB, je použít více bitů v LBA adrese. Třeba v rámci SCSI (a FC a SAS) už od dob U320 existuje možnost LBA64 namísto starého LBA32 (vyžaduje formát rámce CDB16, namísto starého CDB12). Na ATA/SATA už dlouhou dobu funguje adresace LBA48, takže v tomto smyslu disky žádné principielní omezení nemají. Omezení je na straně rozšířených operačních systémů.

To, že se SATA disky momentálně "zastavily na 2 TB" je podle mého spíš shoda okolností. Jednou k tomu dojít muselo, dřív nebo později. Stav technologie disků momentálně neumožňuje výrazně víc, tak proč si komplikovat život tím, že uvedeme disk velký 2.2TB, který stejně spousta Widlí bude detekovat jako 2TB (vyšší adresy nebudou vidět). Vlastně je problém už v PC BIOSu - disk o kapacitě nad 2TB nepůjde opatřit klasickou BIOSovou tabulkou rozdělení, potažmo z něj nepůjde bootovat (pokud budete trvat na využití celé kapacity). Řešením je EFI a jeho GPT (= koupit nový počítač). Nicméně, až bude technologie ploten a hlav dovolovat vyšší kapacitu, tak se nikdo dlouho rozpakovat nebude a větší disky se na trhu objeví.

Konkrétně v Linuxu ještě před nedávnem (řekněme 2 roky zpátky) nebyla podpora sektorů >512B obecně v pořádku. Některé user-space utility s většími sektory nepočítaly a stejně tak některé filesystémy (nebo snad jejich user-space management utility) vykazovaly v těchto situacích chybné chování. Tuším jsem četl poznámky v tom smyslu také o DM/MD subsystémech. Je to maličko paradoxní v tom ohledu, že bloková vrstva v Linuxu 2.6 má odjakživa granularitu přístupů na disk právě 4 kB (je to způsobeno těsným propojením blokové vrstvy s VM = správou paměti, kde je 4kB stránka tradiční), přestože velikost sektoru je stejně tradičních 512B téměř natvrdo. Pokud nevěřite, zkuste "dd if=/dev/zero of=/dev/sdX bs=512" a mrkněte na iostat. Potom totéž s bs=4096. Při velikosti bloku 512B uvidíte dost velký read-ahead, při velikosti bloku 4 kB jenom čistý zápis. Bacha, ten příkaz znamená zápis na disk, cílový disk se smaže do stavu "factory clean" Jinak řečeno, Linux interně dávno dělá to, co teď s velkou slávou zavádí WD do svých disků... a proto vcelku nepochybuji, že "4kB disky" budou v Linuxových kruzích vřele přijaty, a pokud je ještě potřeba něco v kernelu v tomto ohledu optimalizovat, nebude to problém.

Naopak interní podpora LBA64 (a CDB16) v Linuxu je už pár let docela dobrá, i v 32b jádrech (CONFIG_LBD), ačkoli user-space v distribucích taky ještě cca před 3 lety trochu drhnul (podrobnosti si nepamatuju). Pak může být problém s omezeními u jednotlivých filesystémů, ale pokud vím, EXT4, XFS, BTRFS a další moderní FS nikde blízko omezení nemají. XFS na 32b jádře umí max. 16TB. Problém s bootováním přes PC BIOS se týká i Linuxu, ale pokud se nejedná o bootovací disk, tak není problém použít ho nastojato bez rozdělení (lidi od FreeBSD tomu říkají "dangerously dedicated") nebo na něm vyrobit GPT, bez ohledu na to, jestli ho BIOS umí nebo ne.

Mám subjektivní pocit, že některé RAIDy, když nakonfigurujete *venkovní* velikost sektoru na 4 kB, jedou rychleji (proti diskům samozřejmě musí používat 512B sektory). Možná jim to zmenší složitost indexů v interní keši (8x, tj. v průměru o tři patra binárního stromu). Nebo se jim 32b aritmetika s LBA adresami snáz počítá než 64b (ačkoli běžně používané IOP CPU jsou už drahně let interně 64bitové).

[m;)]

pekne

[Stanislav Brabec]

Tvrdit, že u čipu Foveon není nutné data dopočítávat, je poněkud troufalé.

Foveon sice snímá 3 barevné kanály v každém bodu, ale má jednu nepříjemnou vlastnost: Barevné kanály jsou od sebe velmi špatně oddělené a jsou mezi nimi velké silné závislosti.

Což o to, to umí řešit poněkud výrazněji korigující barevný profil, ale to by u Foveonu nestačilo. Po zesílení rozdílu vzniká na barevném signálu několikanásobně vyšší šum než u jasového signálu. Bohužel, lidské oko je na barevný šum mnohem citlivější než na jasový.

Takže se opět dopočitává. Pohledem na okolní pixely se odhaduje, která část signálu je šum a co jsou užitečná data.

Pro srovnání:

Jednoduchá implementace Bayerovy masky v dcraw má 32 řádků.

Implementace filtrování šumu ze snímačů Foveon v dcraw má 661 řádků.

[Kvakor]

Zajímavé. To, že snímač Fovenon XC3 potřebuje také dopočítávání, je jasné už ze zobrazení samotného senzoru - jednotlivé vrstvy jsou přes sebe, takže nezachycují přímo R, G, B, ale spíš R+G+B, R+G a R, a neměří se absolutní velikost napětí, ale jejich rozdíly. Ten problém s barevným šumem ale o dost méně známý, nejspíš k prozatím malému rozšíření tohoto typu snímače.

Je ale pochpitelnější v okamžiku, kdy si uvědomíme, že zatímco senzor s Bayerovou maskou obětuje ve prospěch "pravých" barev prostor chipu (tj. tam, kde se snímá jedna barva, se už nemlůže snímat jiná), Foveon naopak ve prospěch prostoru chipu obětuje "pravé" barvy, protože vrsvy křemíku nejsou moc dobrý barevný filtr a nemohou čistě oddělit jednotlivé vlnové délky.

Tudíž se barvy musejí dopočítat ze vzájemných rozdílů a pokud je zde přítomen šum, tak bude z důvodů různých vlastností vrstev senzoru a jejcih vzájemné závislosti mnohem barevnější než u senzoru s Bayerovou maskou, kde šumí všechny barevné kanály obdobně.

BTW: I z klasického senzoru s Bayerovou maskou můžete dostat "nedopočítávaný" obraz ... pokud vám nevadí, že rozlišení klesne na jednu čtvrtinu. U dcrawu je na to volba -h a celkem se hodí, pokud potřebujete udělat náhledy z RAWů, co nemají v sobě uložený náhled - vzhledem k trivialitě výpočtu je generování výsledného obrazu velmi rychlé.

[DJnero]

Neříká se voda! Říká se pivo!