Administrace komentářů

> Smartctl na SATA disky funguje, musíte mu ale říci, aby pro přístup použil libata,
> jinak se snaží jít přes scsi: smartctl -d ata /dev/sdx (rtfm).

Souhlas, switch "-d ata" je RTFM, jenomže já to vždycky dělal přes Intel ICH on-chip SATA HBA, přes ovladač z frameworku "libata". Tenhle hardware i software má pořád ve střevech nativní podporu ATA. Jak už jsem psal, ovladač Fusion MPT není součástí libata - je to stand-alone SCSI ovladač, historicky to bylo dokonce tupé blokové zařízení - proto by mě příjemně překvapilo, pokud dnes propouští ATA příkazy pro čtení SMARTu ze SATA disků, se kterými je SAS HBA taky jenom "zpětně kompatibilní" (nativní SAS je příbuznější klasickému SCSI)... tvrdíte tedy, že Vám "smartctl -d ata" funguje i na tom LSI SAS řadiči?

Upozorňuju, že smartctl umí fungovat i proti SCSI diskům, ale použité příkazy na SCSI sběrnici jsou jiné a taky struktura výpisu je úplně jiná než u ATA/SATA disků. Pokud zkusíte SCSI SMART IOCTL na SATA disk připojený přes nějaký konzervativní SCSI ovladač (bez ATA passthrough), tak smartctl nevypíše vůbec nic, protože neproleze SCSI ani ATA SMART dotaz.

Ten jumper z výroby je nastavenej na SATA150 kvůli úspoře nákladů firmy Seagate na reklamace. Pořád ještě je venku dost lidí, kteří mají SATA150 HBA kanály, a handshake se SATA300 diskem na nich někdy nefunguje spolehlivě (viděl jsem to na vlastní oči několikrát). A vzhledem k tomu, že nejnovější Barracudy 7200.11 dělají nějakých 125 MBps sekvenčně, tak ten pomalejší kabel aspoň na první pohled není taková tragédie (pokud neuvažujete přístup do cache). Na tom jumperu je otravná jediná věc: jde dost těžko ven (není pořádně za co chytit). Pořád je to menší opruz, než když třeba svého času disky Hitachi chodily nastavené na SATA150 *softwarově*, a daly se přepnout jedině softwarem na nativním SATA HBA kanálu v IDE emulaci na standardních I/O portech - takže když to člověk cpal do RAIDu, tak se na to mohl buď vykašlat, nebo disky po dvojicích / po čtveřicích připojovat do nějakého stolního PC s CD-ROM mechanikou... Hitachi do RAIDu už pár let nedáváme, takže je klid

Tu WB cache může mít by default vypnutou disk (jak správně říkáte), nebo to třeba může dělat BIOS řadiče při POSTu (takže ve zdrojácích linuxového ovladače o tom nic nenajdete), údajně to může dělat i firmware SAS řadiče (do toho není vidět vůbec)...

Ten link ohledně NCQ není až tak výživný, mě osobně se líbil <A HREF="https://kerneltrap.org/mailarchive/linux-kernel/2007/7/9/113289">tenhle příspěvek</A>. Pokud jde čistě o optimalizaci řazení seeků, tak je TCQ/NCQ v disku super. V momentě kdy se IO scheduler v rámci OS snaží zohledňovat nějaká další hlediska (viz třeba CFQ), tak si s TCQ/NCQ algoritmem disku můžou "lézt do zelí". Není to černobílé. Asi jako když se snažíte nějak pokročile priorizovat TCP/IP traffic na nějakém ethernetovém portu, a o kus dál Vám to rovnostářsky ořeže cizí router do úzké WAN linky klasickou jedinou frontou... Nakonec se prostě spokojíte s tím, co Vám ukáže nějaký benchmark

Pokud jsem správně pochopil z nějakých ilustrací a popisů jinde, TCQ/NCQ má oproti OS-based IO scheduleru naopak výhodu v tom, že může seeknout údajně i několikrát v rámci jedné otáčky ploten (pokud seek na blízkou sousední stopu vychází dostatečně rychlý), čímž se částečně eliminuje rotační latence - v tom případě může jako optimální vycházet jiné pořadí požadavků, než by se zdálo čistě na základě LBA adresace, kterou uplatňuje OS. Což je ale výhoda jenom ve zmíněném případě, že jediným kritériem optimalizace je co nejúspornější seekování (scheduler "noop"). Což třeba v serveru vůbec nemusí být špatná volba. CFQ je spíš pro optimalizaci doby odezvy mezi interaktivními a dávkovými úlohami na desktopu.

Mě z toho vychází, že třeba v HW RAIDu s velikou WB cache na řadiči (dneska už třeba jednotky GB) se IO scheduler RAIDu s IO schedulerem uvnitř disků vhodně doplňují. RAID ve veliké keši rovná veliký objem požadavků zhruba za sebe podle LBA adres, a disky si to doladí ve své menší keši do lokálního optima.  Zmíněná lokální optimalizace uvnitř disků totiž funguje právě jenom v blízkém okolí okamžité polohy hlavy - pokud jsou seek positions víc rozházené po celé ploše disku, optimální řazení je odhadnutelné už na základě LBA adresy. Pokud je na discích zapnutá WB cache, tak TCQ/NCQ víceméně usnadňuje plné vytížení datového kabelu k disku (diskový scheduler interně pracuje s potenciálně mnohem delší frontou požadavků, než je jeho externí TCQ/NCQ depth). Samozřejmě opět jediným kritériem v RAIDu i v disku je co nejkratší suma seek time... (žádné CFQ se nekoná).