Společnost Fairphone stojící za stejnojmennými mobilními telefony představila (pdf) bezdrátová špuntová sluchátka Fairbuds 2. Opravitelná, s vyměnitelnými bateriemi a tříletou zárukou. Cena 119 eur.
O víkendu 17. a 18. října lze na brněnském výstavišti navštívit s jednou vstupenkou dvě akce: Maker Faire Brno, festival inovací, kreativity a kutilství, a GameDev Connect, akci určenou pro všechny současné a hlavně budoucí herní vývojáře.
Canonical vydal (email) Ubuntu 26.10 Stonking Stingray. Přehled novinek v poznámkách k vydání. Jedná se o průběžné vydání s podporou 9 měsíců, tj. do července 2027.
České Radiokomunikace (CRA) ve čtvrtek odstřelily rozhlasový vysílač Liblice B, dosud nejvyšší stavbu v Česku. O demolici dvou 355 metrů vysokých stožárů rozhodly z důvodu jejich nevyužívání, už v úterý přitom zhasly a demontovaly jejich osvětlení.
Microsoft Defender nově podporuje linuxové desktopy.
Oficiální Epic Games Launcher je v nové preview verzi poprvé dostupný i pro Linux (FAQ). Pracuje se na novém Easy Anti-Cheatu pro Linux (EAC Linux v2) a podpoře hry Fortnite na Linuxu.
Desktopové prostředí KDE Plasma bylo vydáno ve verzi 6.8. Novinky zahrnují lepší podporu vzdálené plochy, sdílení a nahrávání obrazovky a řadu drobností napříč uživatelským rozhraním (úplný seznam změn, shrnutí ve wiki).
Apple představil 7palcový displej Apple HomeView s podporou Apple Intelligence a Siri AI pro ovládání chytré domácnosti, novou řadu vybavení chytré domácnosti Apple Home Collection, další generaci HomePodu mini a novou Apple TV 4K. Apple HomeView není v Evropské unii v prodeji, jelikož umělá inteligence Siri v rámci systému iOS v EU momentálně není k dispozici. Apple spolupracuje s EU a snaží se najít cestu, jak situaci vyřešit.
KDE slaví 30 let. Přesně před 30 lety, 14. října 1996, poslal Matthias Ettrich do diskusní skupiny comp.os.linux.misc zprávu, která započala historii projektu KDE. Důležité milníky jsou zobrazeny na časové ose.
Byl vydán Mozilla Firefox 158.0. Stejně jako Chrome 155 s podporou JPEG XL (test). Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 158 bude brzy k dispozici také na Flathubu a Snapcraftu.
To já fakt nevím, co dělá linux když něco nemůže přečíst. Že by posílal požadavek disku pořád dokola? Nebo že by disku opravdu tak dlouho trvalo, než to skutečně vzdá? Pole samozřejmě nemá důvod čekat, dávno si data dopočítá o odešle.
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x0008 083 082 000 Old_age Offline - 115001966 3 Spin_Up_Time 0x0006 098 098 000 Old_age Always - 0 4 Start_Stop_Count 0x0013 098 098 020 Pre-fail Always - 2370 5 Reallocated_Sector_Ct 0x0013 100 100 036 Pre-fail Always - 23 7 Seek_Error_Rate 0x0009 052 048 030 Pre-fail Offline - 1374444414102 9 Power_On_Hours 0x0012 092 092 000 Old_age Always - 7678 10 Spin_Retry_Count 0x0013 100 100 090 Pre-fail Always - 0 12 Power_Cycle_Count 0x0013 096 096 000 Pre-fail Always - 4978 197 Current_Pending_Sector 0x0030 100 100 000 Old_age Offline - 0 198 Offline_Uncorrectable 0x0030 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x000a 200 200 000 Old_age Always - 12A moje nastavení:
/dev/hda: multcount = 32 (on) IO_support = 3 (32-bit w/sync) unmaskirq = 0 (off) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead = 256 (on) geometry = 19846/16/63, sectors = 20005650, start = 0Staré Seagaty doporučuji, jsou levné a opravdu kvalitní například oproti WD, nebo IBM (ale to jsou jenom moje zkušenosti)...
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 3270 9 Power_On_Hours 0x0032 092 092 000 Old_age Always - 3435ale prednedavnom som si uz vsimol nejake divne zvuky, ako keby nemazali loziska (keby tam ovsem nejake boli - tipujem, ze uz na vacsine/vsetkych (aspon 2.5'') diskov su fluidne :))
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000b 100 100 051 Pre-fail Always - 4 4 Start_Stop_Count 0x0032 097 097 000 Old_age Always - 4035 5 Reallocated_Sector_Ct 0x0033 253 253 010 Pre-fail Always - 0 7 Seek_Error_Rate 0x000b 253 253 051 Pre-fail Always - 0 8 Seek_Time_Performance 0x0024 253 253 000 Old_age Offline - 0 9 Power_On_Hours 0x0032 099 099 000 Old_age Always - 882820 12 Power_Cycle_Count 0x0032 099 099 000 Old_age Always - 1773 194 Temperature_Celsius 0x0022 133 100 000 Old_age Always - 35 197 Current_Pending_Sector 0x0033 253 253 010 Pre-fail Always - 0 198 Offline_Uncorrectable 0x0031 253 253 010 Pre-fail Offline - 0 199 UDMA_CRC_Error_Count 0x000a 100 100 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x000b 100 100 051 Pre-fail Always - 0 201 Soft_Read_Error_Rate 0x000b 100 100 051 Pre-fail Always - 0To vypadá celkem dobře, ne? zvlášť když na začátku mám
SMART overall-health self-assessment test result: PASSED
Power_On_Hours 0x0032 099 099 000 Old_age Always - 882820se mi nejak nezda...
pokud je to v hodinach, tak to odpovida dobe nejakych 100let
Pro ilustraci jeden 3 roky stary Seagate:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 758 9 Power_On_Hours 0x0032 074 074 000 Old_age Always - 23465 12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 433(jsou uvedeny jen nektere polozky)
...podivejte se na teplotuHm, 35°C se mi nezdá jako nereálná hodota.
Doporučuju ve smartctl -a koukat i na error log. Pokud obsahuje nějaké chyby, je to nejlepší indikátor, že se něco děje a co se přesně děje.
Když disk při pokusu o čtení zjistí, že narazil na vadný sektor, tak to může dopadnout několika způsoby:
1) čtení trvá o něco déle, ale proběhne, a disk provede transparentní relokaci sektoru (nedojde ke ztrátě dat)
2) disk po pár pokusech vrátí OS chybovou hlášku, že "DriveReady SeekComplete Error". A pak sektor realokuje bez záchrany dat, tj. netransparentně. Takže při novém pokusu o čtení sektor přečte z náhradního umístění, ale jsou v něm halušky. Tato chyba by se měla správně objevit ve SMART logu.
3) disk se odmlčí, OS nahlásí timeout ATA/SCSI příkazu. Po rebootu se disk buď sebere a tváří se jako že nic (správně by mu měla přibýt chyba ve SMART error logu resp. "Grown defects listu"), nebo už to nerozchodí.
Obdobně to může dopadnout při zápisu, i když tady mi není jasné, nakolik disk může při zápisu odhalit vadný sektor, zda dělá validaci zapsaných dat, nebo zda prostě v některých případech nedokáže zaseekovat na stopu (nalézt pod hlavou naváděcí režijní značky)... - domnívám se, že B je správně.
Obvyklé chyby při čtení hlášené samotným diskem jsou dvou druhů: buď disk přečte ze sektoru data, která mají vadný checksum, nebo ani nedokáže zaseekovat na stopu. V Linuxu se tohle dá rozlišit z chybového kódu, případně ze SMART error logu (obsahuje tytéž informace). Interpretace ATA příkazů a chyb se dá dohledat na internetu.
No a pak jsou odchylky od očekávaného chování. Typický příklad: chyba se nedostane do SMART logu / grown defects listu, disk se při čtení tváří hrozně spokojeně, SMART error log je čistý, ale při pokusu o zápis padne disk na hubu (a po rebootu opět to samé). On totiž SMART ukládá svoje data taky jenom do nějakého režijního "SMART" sektoru na plotně (doslova 512 B), který není přímo adresovatelný. No a když má fatální problém se zápisem, tak už nezapíše ani ten SMART sektor. Taky se vyskytují bugy ve firmwaru disků. Přijde mi, že některé disky třeba na error log vysloveně kašlou.
Některé disky mají SMART "vypnutý". To se pozná ve chvíli, kdy se pokusíte o smartctl -a. Dá se pomocí této utility zapnout. Není mi ale jasné, zda ve vypnutém stavu disk vede statistiky (a je pouze vypnuté vnější rozhraní SMARTu), nebo zda při vypnutém SMARTu disk prostě nic nesleduje.
V RAIDu může být jistě problém s nějakým vaklem v hot-swap rámečku, nebo s přehříváním elektroniky disku - pak se chyba "opraví" vytažením a zasunutím disku. Podobně se ale chová disk při netranspaentní realokaci sektoru - ta by měla být vidět ve SMARTu, nejlépe jak ve statistice tak v error logu. Ostatně by měla být vidět taky jako událost v logu RAIDu, pokud RAID takovou věc má.
S RAIDy obecně je ten problém, že není vidět přímo na disk, takže nelze použít smartctl/scsiinfo - ledaže vypnete RAID a disky si připojíte na prostý HBA nebo onboard SATA kanál. Různé RAIDy poskytují různou úroveň podrobností ze SMART statistiky jednotlivých disků. Docela dobře je na tom Areca, z ní lze například vyrazit kompletní statistiky (surový SMART sektor) na dálku pomocí ovládací knihovny přes TCP/IP, inband přes SCSI nebo u interních PCI karet přímo přes PCI. (Něco se dá taky zjistit pollingem přes SNMP.) Bohužel ale nejde získat SMART error log - v hlavičkovém souboru knihovny je poznámka, že "tento SMART příkaz není implementován", patrně ani ve firmwaru. Nejedná se o prosté passthrough ATA SMART příkazů, číselné kódy příkazů jsou jiné.
Periodickou kontrolu povrchu disků umí tuším jakýkoli Adaptec AACRAID (SCSI, SATA, SAS), údajně má něco na ten způsob Areca apod. Externí Accusys umí dokonce nastavit den a hodinu, kdy se má scrubbing spustit (ale má zase jiné mouchy).
SMART sledují i ty nejlevnější externí RAIDové řadiče od Arecy a Accusysu. U interních RAIDů do PCI nemám přehled (kromě Arecy). U dražších a větších storage mrazáků taky nemám tušení.
Na vícečetné výpadky disků je dobrý RAID6 - přežije výpadek libovolných dvou disků.
Tiskni
Sdílej: