Nová čísla časopisů od nakladatelství Raspberry Pi: MagPi 140 (pdf) a HackSpace 77 (pdf).
ESPHome, tj. open source systém umožňující nastavovat zařízení s čipy ESP (i dalšími) pomocí konfiguračních souborů a připojit je do domácí automatizace, například do Home Assistantu, byl vydán ve verzi 2024.4.0.
LF AI & Data Foundation patřící pod Linux Foundation spustila Open Platform for Enterprise AI (OPEA).
Neziskové průmyslové konsorcium Khronos Group vydalo verzi 1.1 specifikace OpenXR (Wikipedie), tj. standardu specifikujícího přístup k platformám a zařízením pro XR, tj. platformám a zařízením pro AR (rozšířenou realitu) a VR (virtuální realitu). Do základu se z rozšíření dostalo XR_EXT_local_floor. Společnost Collabora implementuje novou verzi specifikace do platformy Monado, tj. open source implementace OpenXR.
Byla vydána nová verze 0.38.0 multimediálního přehrávače mpv (Wikipedie) vycházejícího z přehrávačů MPlayer a mplayer2. Přehled novinek, změn a oprav na GitHubu. Požadován je FFmpeg 4.4 nebo novější a také libplacebo 6.338.2 nebo novější.
ClamAV (Wikipedie), tj. multiplatformní antivirový engine s otevřeným zdrojovým kódem pro detekci trojských koní, virů, malwaru a dalších škodlivých hrozeb, byl vydán ve verzích 1.3.1, 1.2.3 a 1.0.6. Ve verzi 1.3.1 je mimo jiné řešena bezpečnostní chyba CVE-2024-20380.
Digitální a informační agentura (DIA) oznámila (PDF, X a Facebook), že mobilní aplikace Portál občana je ode dneška oficiálně venku.
#HACKUJBRNO 2024, byly zveřejněny výsledky a výstupy hackathonu města Brna nad otevřenými městskými daty, který se konal 13. a 14. dubna 2024.
Společnost Volla Systeme stojící za telefony Volla spustila na Kickstarteru kampaň na podporu tabletu Volla Tablet s Volla OS nebo Ubuntu Touch.
Společnost Boston Dynamics oznámila, že humanoidní hydraulický robot HD Atlas šel do důchodu (YouTube). Nastupuje nová vylepšená elektrická varianta (YouTube).
Zdravím,
mám problémy s výkonem nových disků. Na nfs (/home) serveru, kam se připojuje (zejména) aplikační server s LTSP, jsem kvůli odcházejícímu disku v RAIDu jsem odstranil původní raid0 (strip) se 2x200Gb (celkem 400Gb) Barracudami, SATA (ne SATA II) na onboard řadiči. Místo nich jsem koupil nový řadič SATA II do PCI-X a na něj pověsil 4x700Gb Barracuda es(.2) v raid10 (celkem tedy 1.4TB). Na raidu je ext3 (interní žurnál, parametry default), server debian lenny, nfs klient ubuntu hardy.
NFSko se výměnou disků bohužel znatelně zpomalilo (takže load average občas i několik minut 20, wait 80% apod.); podle iostatu výrazně převažuje zápis (3:1 proti čtení).
Díky za jakékoliv nápady.
Tak si odpovídám sám: zdá se, že zpomalení výkonu způsobovala vypnutá write-cache u harddisků. (podle diskuse na rootu -- možná už je zastaralá?): Linux (jádro) nemá příkaz flush-cache, proto write-cache u disků implicitně zakazuje. Po použití hdparm -W1 /dev/sdc ... na všechny disky v raidu se rychlost subjektivně zásadně zvýšila.
Takhle vypadal starý dmesg:
SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: drive cache: write back
a takhle vypadá nový:
[ 61.267195] sd 2:0:0:0: [sdc] 1465149168 512-byte hardware sectors (750156 MB) [ 61.423695] sd 2:0:0:0: [sdc] Write Protect is off [ 61.423805] sd 2:0:0:0: [sdc] Mode Sense: 73 00 00 08 [ 61.425794] sd 2:0:0:0: [sdc] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
Otázka je, proč se to projevilo až s novými disky? Napadá mě jen, že ty staré barracudy 7200.7 vůbec vypnutí/zapnutí cache zvenčí neumožňovaly a implicitně byla zapnutá, kdežto nové to umožňují a kernel ji vypne.
Konečně, hrozí nějaké zásadní nebezpečí, když je server na UPSce, která by ho měla po několika minutách bez proudu bezpečně vypnout? Nebo mám při výpadku proudu pustit hdparm -W0 a když naskočí zase hdparm -W1?
Post scriptum: zkoušel jsem do toho LSI řadiče připojit starou Barracudu a write-cache měla vypnutou; zatímco na oboard SATA, jak to bylo předtím, byla bez dalšího zapnutá.
Takže je to default řadiče, že vypne cache, nikoliv disků. Nebylo mi to předtím jasné.
Ještě jedna otázka zkušenějším: TCQ(tagged command queuing) by měl zvýšit výkon podobně jako write-cache, ale způsobem, který nezvyšuje riziko ztráty dat při výpadku proudu. Podporuje to Linux (2.6.26 v tomto případě), kde se případně dočíst o podpoře na řadičích a na diskách? Díky.
Už jste to vyřešil sám, závěr je pro mě osobně dost překvapivý a zajímavý, gratuluji a děkuji za informaci. Na SATA disk připojený přes LSI SAS řadič funguje "hdparm"? No to je geniální... ještě kdyby fungoval smartctl 
Snad jen pár poznámek na okraj:
Z Vašich poznámek jsem nabyl dojmu, že řadič "HP" (LSI) používáte jako tupý HBA a RAID 10 používáte nativní Linuxový softwarový (ne nějaký proprietární soft-RAID ovladač od LSI). Pokud je to tak, děláte to správně.
Ten původní SATA řadič od AMD byl obsluhován jiným driverem (něco v rámci libata nebo stand-alone driver ve "scsi low-level drivers") než Váš nový řadič, který je podle všeho osazen čipem LSI SAS z rodiny Fusion MPT (ovladač mptsas.ko?). Možná je rozdíl v zacházení s cache uvnitř disku daný právě tím. Driver LSI message/fusion býval zaháknut do vrstvy blokových zařízení, spíš než do jednotné kernelové vrstvy SCSI - to už zřejmě není pravda, ve zdrojákách je spousta odkazů na obecné linuxové SCSI struktury, takže staré časy už asi připomíná jenom samostatný adresář ovladače, mimo jednotný drivers/scsi...
Pokud se nepletu, tak SATA NCQ stejně jako SCSI/SAS/FC TCQ je mapováno na jednotný queueing SCSI požadavků linuxové SCSI vrstvy. (Aspoň doufám, že si to ovladač message/fusion dodnes nedělá sám...). Každopádně pokud se nepletu aktuální default queue depth v ovladačích LSI je tuším 128 (bacha, nejedná se zřejmě o položku CONFIG_FUSION_MAX_SGE v .config, ale spíš o podobně znějící makra v souboru mptbase.h.)
Dále si přihřeju polívčičku: zatímco Bonnie je benchmark a tester souborových systémů, já mám jednoduchý tester na sekvenční a "random access" průchodnost blokového zařízení - výsledky jsou vidět okamžitě a jsou poměrně pochopitelné:
http://www.fccps.cz/download/adv/frr/hddtest-1.0.tgz
sice to taky jede skrz blokovou cache (žádný O_DIRECT) ale dává to docela rychlý přehled o zdravotním stavu disku/řadiče/PCI, pokud víte, kolik zhruba máte čekat. Je z toho třeba na první pohled vidět Intel ICH SATA řadič nastavený do suboptimálního režimu (pokud je použit) nebo disk s vážnými problémy (kolísání sekvenční rychlosti).
Dnešní Barracudy mají příjemnou sekvenční průchodnost, ale rychlost seekování není nijak závratná - vyšší hustota záznamu zřejmě vyžaduje delší dobu ustálení po každém seeku. Nejnovější cheetahy 15k seekují nejmíň dvakrát rychleji. Každopádně dnešní Barracuda by ani v tomto ohledu neměla být znatelně horší než 3-4 roky starý disk. Spíš pozor na závadu konkrétního kusu - nápadně pomalá průchodnost jednoho disku může znamenat blížící se vadné sektory a typicky brzdí celý RAID. Pokud máte možnost otestovat disky jednotlivě (aspoň na čtení to jde i při nahozeném RAIDu), tak je trochu provětrejte.
Ohledně write-back cache: moje zkušenost je, že s vypnutou write-back keší se prakticky nedá pracovat. Pro většinu použití to není zásadní problém - vypnutí WB cache zvažte jenom v případě, že se *opravdu hodně* bojíte o svá data.
Ti LTSP klienti, jak velké soubory vyrábějí? Na maličké soubory by možná byl lepší Reiser 3...
Taky jsem měl svého času pocit, že mi za jistých okolností CFQ serializuje čtecí požadavky od více vláken, takže se mi požadavky nerozložily mezi více "spindlů" v RAIDu. Přechod na čistý FIFO scheduler ("noop") přinesl zásadní nárůst průchodnosti (lepší škálování) při paralelním přístupu více user-space vláken. (echo "noop" > /sys/block/hda/queue/scheduler). Ale to se týkalo přístupu k HW RAIDu na 24 discích - pro 4 disky ten rozdíl nemusí být výrazný. Měl jsem pocit, že když použiji ovladač pro Qlogic HBA zakompilovaný monoliticky, tak mi CFQ funguje rozumně, ale když ho zkompiluju jako modul a loadnu až za jízdy, tak se CFQ pro nově detekovaný disk chová popsaným způsobem...
Díky za obsáhlou odpověď, prakticky se tím prokoušu časem a dám vědět.
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: hdparm -d ata /dev/sdx (rtfm). Teď na lennym to už, zdá se, není třeba, i když v manuálové stránce se o tom pořád píše.
Řadič používá modul mptsas (lspci: LSI Logic / Symbios Logic SAS1068 PCI-X Fusion-MPT SAS), až budu mít další SF8484->SATA kabel, zkusím připojit staré disky, jak se to zachová, jednou přes ten LSI, jednou přes původní onboard. Zkusím nezapomenout napsat.
Zdá se, že žádný disk neodchází, hdparm -Tt dává na všech zhruba stejné hodnoty. Vedle toho jsou nové, tak snad ještě... 
O data se *opravdu hodně* nebojím, všechno se zálohuje a vedle toho když vypadne proud, spadnou první ti tencí klienti, kde lidi budou mít rozdělanou práci (i když server pojede přes UPS). Nerozumím tomu, proč by řadič write-cache defaultně zakazoval (to je něco podobného, jako že na těch nových Barracudách je z výroby jumper, který je třeba rozpojit, aby se povolilo 3Gb/s!! Proč není default to, co většina lidí spíš bude chtít?) Na kerneltrap jsem o NCQ/TCQ a writeback cachi teď vygooglil thread, to si ještě přečtu.
LTSP klienti vytvářejí to co tam většinou běží: firefox, openoffice, gimp; takový ten typický bordel co bývá v /home. Teď už je to bez problémů, zdálo se ale, že většina (malých) zápisů jsou historie firefoxu, cookies, nějaké tempy apod.
Díky za ten váš nástroj, to se bude hodit.
> 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á).
tvrdíte tedy, že Vám "smartctl -d ata" funguje i na tom LSI SAS řadiči?
Ne, na něm to funguje bez -d ata. (Upřímně řečeno, o tom jak spolu interaguje jádro, řadič a disk toho vím pomálu, takže všechno co píšete je moc zajímavé čtení - díky ). Jo a ten raid10 je softwarový; hw raidy jsem zkoušel jen málo (a byly to asi ty levnější, i když už opravdové a ne fake-raidy) a přišlo mi, že se mizerně ovládají (nějaké utilitky co se dají pustit před bootem).
random read: xx Mbps random write: yy Mbps avg seek: xx ms sequential read: xx Mbps sequential write: yy MbpsZdenek
Hddtest bere jenom bloková zařízení, ne prosté soubory. Pokud chcete testovat sekvenční průchodnost proti filesystému, zkuste dd, doporučuji bs=4096. Hddtest taky neposlouží statistikou "avg seek" - pokud tuhle statistiku měříte nějakým benchmarkem, tak je syntetická, a pokud jde o reálnou zátěž, tak netuším, jak ji ze systému získat (latencytop?) Hddtest umí sekvenční a čistě náhodné čtení (případně zápis, s parametrem -w => bacha, přepíše data).
> dd testuje filesystem? Jasne, muzu to postvat na nejaky soubor na tom filesystemu,
> ale to ma nulovou vypovidaci hodnotu.
Proc myslite? Kdyz hrnete data z /dev/zero do souboru nad FS, tak otestujete prave surovou sekvencni pruchodnost do filesystemu. Pokud strihate HD video, tak tento udaj ma uzitkovou hodnotu docela dobrou Filesystem pridava do sekvencniho toku svoje vlastni seeky navic, takze sekvencni pruchodnost do FS bude oproti holemu blokovemu zarizeni mensi.
> Dobu seeku jsem zatim nezmeril vubec nicim.
Mam pocit, ze [ avg.seek = 1 / Tps ] : co vy na to?
Muj hddtest reportuje pocet svych read()/write() volani za sekundu. Mozna presnejsi je ale hodnota ziskana z iostatu (utilita z baliku sysstat), ten hlasi Tps na rozhrani s diskem. Pokud spustite hddtest -2 (nebo si pockate, az hddtest bez argumentu dojede do faze nahodnych pristupu), tak mate moznost pozorovat Tps pro "seek positions" generovane nahodnym generatorem. To je IMO nejobtiznejsi load, jaky se realne muze vyskytnout, treba pri zaplnenem filesystemu - pokud po disku nechcete prevazujici seekovani mezi dvema vzdalenymi partisnami, pristup na FAT FS s IO barierami apod. Hodnoty avg.seek pri nahodnem seekovani jsou dost pesimisticke
> Jde mi o tech 6 disku co mam, obavam se, jestli RAID-0 nebude mit obrovsky
> overhead prave v tom nez vsechny disky najedou tam kam maj.
Obecne u stripovanych poli to berte tak, ze [seek time celeho stripe setu] == [seek time nejpomalejsiho disku]. Cili nejpomalejsi disk = uzke hrdlo. Ale plati to jenom v pripade, ze potrebujete precist nebo zapsat cely stripe set naraz - tj. typicky pri operacich s paritou, nebo obecne pri transakci vetsi nez je stripe set size.
Konkretne u RAIDu 0 se nepocita zadna parita, takze cteni a zapis se chovaji cca stejne. Pokud je transakce mensi nez stripe size (a navic zarovnana dovnitr jednotliveho stripu), tak se zapis i cteni tykaji jedineho disku, a uplatni se pouze jeho individualni seek time. Obecne se uplatni seek time tech disku, kterych se tyka konkretni transakce...
Pri cteni celeho stripe setu (nebo jenom vice stripu vedle sebe) jednotlive disky seekuji a ctou paralelne, takze seek times se nescitaji - pro dokonceni transakce je rozhodujici seek time nejpomalejsiho disku, ostatni to proste "stihly rychleji".
Nejake slozitejsi interakce mezi seek times ruznych disku necekejte - krome toho uzkeho hrdla u vetsich transakci. Ted si nejsem jistej, jestli RAID nahodou nerozebere i zapisy celych stripe setu mezi jednotlive disky. Treba kdyz Areca inicializuje pole nulama (aspon nova SASova Areca), tak nektere disky dokonci inicializaci driv a nektere pozdeji - takze zjevne na sebe navzajem "necekaji"... Pokud by se RAID takto choval i s uzitecnymi daty, tak by pri zapisu to uzke hrdlo na pomalem disku vyniklo az po zaplneni WB cache RAIDu. Tim se dostavame k tomu, ze radic RAIDu muze cachovat "drive side" nebo "host side" transakce, nebo oboje adaptivne podle potreby - ale to je myslim uz jina pohadka, navic prakticky nedokumentovana...
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz