Americký výrobce čipů Nvidia získal od vlády prezidenta Donalda Trumpa souhlas s prodejem svých pokročilých počítačových čipů používaných k vývoji umělé inteligence (AI) H20 do Číny. Prodej těchto čipů speciálně upravených pro čínský trh by tak mohl být brzy obnoven, uvedla firma na svém blogu. Americká vláda zakázala prodej v dubnu, v době eskalace obchodního sporu mezi oběma zeměmi. Tehdy to zdůvodnila obavami, že by čipy mohla využívat čínská armáda.
3D software Blender byl vydán ve verzi 4.5 s prodlouženou podporou. Podrobnosti v poznámkách k vydání. Videopředstavení na YouTube.
Open source webový aplikační framework Django slaví 20. narozeniny.
V Brestu dnes začala konference vývojářů a uživatelů linuxové distribuce Debian DebConf25. Na programu je řada zajímavých přednášek. Sledovat je lze online.
Před 30 lety, tj. 14. července 1995, se začala používat přípona .mp3 pro soubory s hudbou komprimovanou pomocí MPEG-2 Audio Layer 3.
Výroba 8bitových domácích počítačů Commodore 64 byla ukončena v dubnu 1994. Po více než 30 letech byl představen nový oficiální Commodore 64 Ultimate (YouTube). S deskou postavenou na FPGA. Ve 3 edicích v ceně od 299 dolarů a plánovaným dodáním v říjnu a listopadu letošního roku.
Společnost Hugging Face ve spolupráci se společností Pollen Robotics představila open source robota Reachy Mini (YouTube). Předobjednat lze lite verzi za 299 dolarů a wireless verzi s Raspberry Pi 5 za 449 dolarů.
Dnes v 17:30 bude oficiálně vydána open source počítačová hra DOGWALK vytvořena v 3D softwaru Blender a herním enginu Godot. Release party proběhne na YouTube od 17:00.
McDonald's se spojil se společností Paradox a pracovníky nabírá také pomocí AI řešení s virtuální asistentkou Olivii běžící na webu McHire. Ian Carroll a Sam Curry se na toto AI řešení blíže podívali a opravdu je překvapilo, že se mohli přihlásit pomocí jména 123456 a hesla 123456 a získat přístup k údajům o 64 milionech uchazečů o práci.
Byla vydána (𝕏) červnová aktualizace aneb nová verze 1.102 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.102 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Ať už používáme RAID pole na serverech či desktopech, je dobré mít na paměti několik bodů. Předesílám, že tyto body jsem nashromáždil při svých úvahách, podpořených čtením mnoha článků na Webu a jistou osobní zkušeností, která ale v této oblasti není ani zdaleka tak velká, abych měl nárok považovat se za odborníka. Naopak očekávám, že místní odborníci mě vyvedou z omylu, že o diskových polích něco málo vím.
Správci serverů tohle obvykle vědí, ale ostatní si to často neuvědomují. Ano, RAID mne obvykle (pokud to zrovna není RAID 0) ochrání před výpadkem minimálně jednoho disku. Ale přijít o data lze i bez poruchy pevného disku. Může se porouchat řadič, může být v jádře operačního systému chyba, která bude pěkně potichu kazit data (nebo následkem které pole zkolabuje), může zkolabovat souborový systém nad polem, no a nebo může uživatel důležitý soubor omylem vymazat sám. Data by tedy měla být zálohována bez ohledu na to, jaký RAID byl použit.
Máme nějaký RAID, který je schopen přežít výpadek jednoho disku. Dříve nebo později k výpadku dojde. V tu chvíli se nám spouští pomyslné stopky. Objednáme náhradní disk, náhradní disk dorazí k nám, my vyměníme vadný disk a nainstalujeme nový. Hotovo? Nikoliv. Pole je třeba rekonstruovat. Rekonstrukce může trvat v závislosti na mnoha parametrech i desítky hodin. V tu dobu je pole nejzranitelnější - nejenom, že ještě nemáme pole v celku, ale při rekonstrukci dochází ke značnému vytížení zbývajících disků.
Jaká je pravděpodobnost, že selže i nějaký z dalších disků, a pole se odebere do věčných lovišť? Pole má za sebou již nějakou dobu provozu, disky již dávno nejsou čerstvě dovezené z továrny, a ještě k tomu dochází při rekonstrukci k jejich značnému vytížení. Pravděpodobnost selhání je tedy vysoká. I to je důvodem, proč se před rekonstrukcí doporučuje aktualizovat zálohu (zálohujete přece dle bodu I.?). I samotné zálohování bude představovat vytížení pole, ale pokud budete provádět pouze přírůstkovou zálohu (nebo nějaký ten rsync), bude dopad zálohy podstatně menší než dopad rekonstrukce pole.
Sen každého z nás je pole jednou vytvořit a už se o něj nestarat. Maximálně časem (a v klidu) vyměnit nějaký ten vadný disk. Jenomže je třeba mít na paměti, že disky se časem opotřebovávají a pravděpodobnost jejich selhání časem vzrůstá.
U pevných disků, které pracují 24 hodin denně bez přestávek, pak za čas hrozí problém s mazivem/lubrikantem, který vyschne nebo po vypnutí ztuhne. To pak může způsobit, že u dlouho běžícího pole bude do výpadku proudu všechno v pořádku, a po opětovném zapnutí se několik disků prostě už neroztočí. Co to udělá s polem je snad jasné...
Aby to nebylo jednoduché, existuje "kojenecká úmrtnost", kdy nové disky mohou mít různé výrobní vady, které se obvykle projeví brzy při nebo po jejich zahoření, čili, na počátku života disku je relativně vyšší pravděpodobnost selhání, která se za čas sníží na jistou úroveň, která po několika letech začne opět růst, a poroste až do doby selhání. Viz studie.
Poměrně zajímavým článkem byl tento, který v podstatě říká, že zatímco kapacity disků se zvyšují, pravděpodobnost výskytu chyby čtení vztažená k množství čtených dat zůstává konstatní. Proto se s rostoucí kapacitou disků zvyšuje pravděpodobnost selhání rekonstrukce RAIDu 5. Článek dokonce říká, že brzy nebude stačit ani RAID 6.
K tomu se váže i jedna moje nedávná zkušenost, kdy dva pevné disky z degradovaného RAID 6 pole (5 ze 6 disků) vypadly velmi krátce (sekundy/minuty) za sebou v důsledku chyby čtení, následkem čehož zkolablovalo celé pole (naštěstí na něm ještě nebyla žádná data). Disky byly připojené každý přes jiný SATA řadič. SMART disků hlásil v obou případech jedničku u Reallocation Event Count, následné SMART testy potvrdily chybu při čtení daného sektoru. Disky jsem projel nástrojem badblocks
, který příslušné sektory přepsal. Realokovat je nebylo třeba, zápis se podařil, takže jednička skončila ve SMART hodnotě 198 (Uncorrectable Sector Count). Příčinu s největší pravděpodobností přisuzuji dřívějšímu výpadku napájení, který nastal během zápisu na pole (příště se z těmi zatěžkávacími zkouškami budu mírnit...).
SMART je úžasná technologie, jejíž ambice je předvídat mechanickou poruchu disku ještě před tím, než nastane. Problémem je, že odhalí pouze jisté typy problémů. V mnoha případech chybu předpovědět nedokáže. Jeho vypovídací hodnotu bych spíše bral tak, že pokud SMART říká, že disk je v háji, má pravdu. Pokud SMART říká, že je všechno v pořádku, to ještě vůbec nic neznamená.
SMART je nicméně vynikajícím pomocníkem při diagnostice problémů s pevnými disky. Pokud příslušné SMART hodnoty interpretujete správně, mnohdy vám napoví, kde je zakopán pes. Naučit se SMART údaje číst a správně interpretovat ovšem není vůbec jednoduché. Začít můžete tady.
A co vy? Jak se díváte na problematiku diskových polí? Máte další tipy a zkušenosti? Sem s nimi.
Měl bych dodat, že tento zápisek jsem publikoval také na svém soukromém blogu, ale tam si ho nepřečte tolik lidí jako tady. A hlavně mi tam tolik lidí nebude vyvracet případné omyly, kterých jsem se ve svých úvahách dopustil, a o to mi jde především.
Tiskni
Sdílej:
A aky je Vas nazor a pripadne skusenosti (rychlost, spravanie sa pri havarii a pod.) pri pouziti LVM nad RAID polom?
Hezke cteni. Docela by mne zajimalo, zda ma nejkdo nejaky ten tip ohledne kopirovani souboru. Kdyz uz se stane, ze pole odejde a je potreba zavest nove a na nej nakopirovat data ze zalohy.
Pokud se jedna napriklad o 300GB dat a casto v malych souborech, tak to i mezi dvema SATA disky trva asi 5 hodin s tim, ze na tech malych souborech je hrozny zasek a kopirovani jde opravdu pomalu.
Je nejaka moznost kopirovat to cele jako nejaky blok? Vim, ze jde napriklad duplikovat cela partition na jiny disk, coz je urcite rychlejsi, nez to kopirovat na urovni filesystemu, ale pokud jsou parition na obou discich jine, tak jak toto resit?
Zkusenost je s ext3...
resize
. U ext3
se to dělá třeba takto.
Mno, ten odkazovaný článek je takový ... až zbytečně moc složitý.
Zvětšení ext3 je triviální. Stačí zvětšit oddíl pod ní a pak už je pustit resize2fs oddíl
. Netřeba umount, netřeba reboot, netřeba live distra a už vůbec není potřeba z ext3 dělat ext2 (odebráním žurnálu). Lze to dělat za běhu systému a s připojeným systémem souborů. Více třeba tady.
Nebo použít nástroj typu xfsdump
a xfsrestore
– tím se dají soubory přenést dost efektivně (lépe než cp
i dd
).
Pokud se jedna napriklad o 300GB dat a casto v malych souborech, tak to i mezi dvema SATA disky trva asi 5 hodin s tim, ze na tech malych souborech je hrozny zasek a kopirovani jde opravdu pomalu.Nepomohlo by posílat to rourou a na jedné straně dělat tar c a na druhé tar x?
Dodal bych pár postřehů:
Pole je možné kontrolovat (echo check >/sys/block/mdX/md/resync_action). Dokonce jsem koukal, že nová Fedora 11 to už dělá každý týden z cronu. Samozřejmě se tím zvyšuje pravděpodobnost, že nějaký disk selže, ale o to přeci jde. Jakmile je jakýkoliv disk tak špatný, že není 100% schopný plnit svojí funkci, tak se musí vyměnit. A u té výměny bych nedoporučoval čekat, až dorazí disk opravený, ale mít po ruce disk nový a rekonstrukci udělat co nejdříve. S tím je taky spojené to, že je dobré mít odzkoušené, zda systém nový disk umí bez restartu najít.
/sys/block/mdX/md/sync_action
, soubor resync_action
jsem v příslušném adresáři neobjevil. Každopádně díky moc za tip.
BTW, ono je také možné do pole přidat nějaký spare disk (třeba i více než jeden), takže hned po případném selhání dojde automaticky k zahájení rekonstrukce pole.
Jo, je to sync_action. Já to vždycky tabkuju a byl jsem línej to dohledávat A pletu si to se souborem v adrsáři pro scsi řadič, kterým se řekne řadiči, ať si rescanuje porty...
Spare disk je zajímavá možnost, ale zase žere slot na disk. A pokud chci mít jeden disk jako spare pro víc polí, tak to "nativně" nejde, ale musí se nakonfigurovat mdadm jako démon a ten ho v případě výpadku připojí. Abych se přiznal, to jsem ještě nezkoušel. A další zajímavost je vzdálený disk připojenž pžes iSCSI v raidu s lokálním, ale to už je zase trochu k něcěmu jinému....
Docela hloupé je, že v takovém případě člověka nemusí zachránit ani ty zálohy – na chybu nepřijdu hned a mezitím zálohy přepíši novějšími (ale zmršenými) daty. Tak snad leda zálohovat přes rsync
a na zálohovacím médiu dělat snapshoty po každé záloze → a mít tak všechny verze – ale v praxi to vyzkoušené nemám, jen mě to tak teď napadlo
rdiff-backup je vyborny,ma vsak jednu pro mne dost podstatnou nevyhodu - je desne pomaly, chapu ,ze dekomprimace neco stoji ,ale i tak ...
dik
Právě. Po zkušenostech s rdiff-backupem přecházíme na nilfs. Zdá se to být elegantním řešení problému.