IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.
Po roce vývoje od vydání verze 1.24.0 byla vydána nová stabilní verze 1.26.0 webového serveru a reverzní proxy nginx (Wikipedie). Nová verze přináší řadu novinek. Podrobný přehled v souboru CHANGES-1.26.
Byla vydána nová verze 6.2 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 13.0.14.
Byla vydána nová verze 30.0.0 frameworku pro vývoj multiplatformních desktopových aplikací pomocí JavaScriptu, HTML a CSS Electron (Wikipedie, GitHub). Chromium bylo aktualizováno na verzi 124.0.6367.49, V8 na verzi 12.4 a Node.js na verzi 20.11.1. Electron byl původně vyvíjen pro editor Atom pod názvem Atom Shell. Dnes je na Electronu postavena celá řada dalších aplikací.
Byla vydána nová verze 9.0.0 otevřeného emulátoru procesorů a virtualizačního nástroje QEMU (Wikipedie). Přispělo 220 vývojářů. Provedeno bylo více než 2 700 commitů. Přehled úprav a nových vlastností v seznamu změn.
Evropský parlament dnes přijal směrnici týkající se tzv. práva spotřebitele na opravu. Poslanci ji podpořili 584 hlasy (3 bylo proti a 14 se zdrželo hlasování). Směrnice ujasňuje povinnosti výrobců opravovat zboží a motivovat spotřebitele k tomu, aby si výrobky nechávali opravit a prodloužili tak jejich životnost.
Bylo oznámeno (cs) vydání Fedora Linuxu 40. Přehled novinek ve Fedora Workstation 40 a Fedora KDE 40 na stránkách Fedora Magazinu. Současně byl oznámen notebook Slimbook Fedora 2.
ČTK (Česká tisková kancelář) upozorňuje (X), že na jejím zpravodajském webu České noviny byly dnes dopoledne neznámým útočníkem umístěny dva smyšlené texty, které nepocházejí z její produkce. Jde o text s titulkem „BIS zabránila pokusu o atentát na nově zvoleného slovenského prezidenta Petra Pelligriniho“ a o údajné mimořádné prohlášení ministra Lipavského k témuž. Tyto dezinformace byly útočníky zveřejněny i s příslušnými notifikacemi v mobilní aplikaci Českých novin. ČTK ve svém zpravodajském servisu žádnou informaci v tomto znění nevydala.
Hezký den,
bohužel jsem zjistil, že se ke svému domácímu serveru nemohu přihlásit přes SSH. Když jsem tedy připojil monitor a klávesnici, viděl jsem mnoho řádků I/O error (ext3-fs error (device md0): ext3_get_inode_loc: unable to read inode block - inode=...). Nešlo se ani přihlásit, nemohl jsem ani pomocí ctrl+alt+del vyvolat reboot. Takže tvrdý reset.
Po resetu jel počítač bez problému. Dnes ale podruhé, úplně ten samý problém.
Na serveru mám nainstalovaný Ubuntu Server 8.10. Jedná se o Intel Little Valley s integrovaným procesorem Intel Atom, 1 GB ram a 2 disky Samsung Spinpoint F1 (HD103UJ) použité pro SW RAID 1 (zvoleno při instalaci systému).
cat /proc/mdstat vypisuje toto:
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 sda2[0]
975587200 blocks [2/1] [U_]
md1 : active raid1 sda1[0] sdb1[1]
1172608 blocks [2/2] [UU]
unused devices: <none>
V kern.log mám napřílad toto:
Sep 6 12:55:53 junior kernel: [ 3806.494192] ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Sep 6 12:55:53 junior kernel: [ 3806.494291] ata3.00: BMDMA stat 0x26
Sep 6 12:55:53 junior kernel: [ 3806.494354] ata3.00: cmd 35/00:00:6a:6f:f0/00:04:0f:00:00/e0 tag 0 dma 524288 out
Sep 6 12:55:53 junior kernel: [ 3806.494488] ata3.00: status: { DRDY ERR }
Sep 6 12:55:53 junior kernel: [ 3806.494537] ata3.00: error: { ABRT }
Sep 6 12:55:53 junior kernel: [ 3806.628486] ata3.00: configured for UDMA/133
Sep 6 12:55:53 junior kernel: [ 3806.628535] ata3: EH complete
Sep 6 12:57:37 junior kernel: [ 3910.812056] ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Sep 6 12:57:37 junior kernel: [ 3910.812134] ata3.00: cmd 35/00:d0:22:23:f2/00:03:0f:00:00/e0 tag 0 dma 499712 out
Sep 6 12:57:48 junior kernel: [ 3910.812276] ata3.00: status: { DRDY }
Sep 6 12:57:48 junior kernel: [ 3915.852024] ata3: link is slow to respond, please be patient (ready=0)
Sep 6 12:57:48 junior kernel: [ 3920.836023] ata3: device not ready (errno=-16), forcing hardreset
Sep 6 12:57:48 junior kernel: [ 3920.836041] ata3: soft resetting link
Sep 6 12:57:48 junior kernel: [ 3921.008372] ata3.00: configured for UDMA/133
Sep 6 12:57:48 junior kernel: [ 3921.008404] ata3: EH complete
Výstup příkazu sudo smartctl -a /dev/sda (resp. sda) jsem vložil do přílohy. U sda jsou vypsány nějaké chyby, kterým nerozumím.
Konečně dotazy:
Předem díky za (v tuto chvíli snad ještě VELMI) cenné rady.
co se to děje? je sda opravdu vadný?Divné - podle smartu je vadný sda, ale z toho RAIDu md0 vypadl sdb2, takže v danou chvíli evidentně jádro usoudilo, že vadný je sdb.
nemohu přijít o data uložená na poli? (nebudou případné chyby mirrorovány i na sdb?)Neměly by - v případě, že jádro zjistí, že nějaký disk v poli je vadný, z pole ho vyhodí.
pokud je sda vadný, mohu jej odpojit a nechat systém běžet krátce jen s jedním diskem?Dokud v RAID1 zbývá alespoň 1 funkční disk, můžeš ostatní disky odpojit a (pokud máš zavaděč všude) systém by měl nadále fungovat.
pokud sda vyndám a nahradím správným kusem, obnoví se pole automaticky, nebo to musím vyvolat ručně?Obnova pole se spustí automaticky, co do něj vložíš nový disk. (Vložíš znamená mdadm /dev/mdZ --add /dev/sdXY, kde X je disk a Y oddíl na tom disku, Z potom číslo md zařízení. Syntax pro ten mdadm si pro jistotu zkontroluj podle manuálu.) Kromě disku ještě může být (s menší pravděpodobností) vadný řadič. Nejjednoduššeji to vyzkoušíš, když ten vadný disk (až přidješ na to, který to je) vyndáš a otestuješ v jiném počítači.
Ahoj. Díky za reakci.
Zapomněl jsem uvést, že mám oba disky rozdělené na 1 GB swap (sda1,sdb1 = md1) a zbytek do 1 TB na / (sda2,sdb2 = md0).
Bohužel nevím, jak by měl vypadat výstup z /proc/mdstat, ale předpokládám, že by u md0 i md1 měly být uvedeny oba disky (tedy ne jen sda). Je to tak?
Podívej prosím na tohle:
sudo mdadm --query --detail /dev/md1
/dev/md1:
Version : 00.90
Creation Time : Sat Dec 20 20:01:36 2008
Raid Level : raid1
Array Size : 1172608 (1145.32 MiB 1200.75 MB)
Used Dev Size : 1172608 (1145.32 MiB 1200.75 MB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 1
Persistence : Superblock is persistent
Update Time : Sun Sep 6 13:29:44 2009
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
UUID : bf9893c6:c6602749:ef907f74:7a4ad805
Events : 0.40
Number Major Minor RaidDevice State
0 8 1 0 active sync /dev/sda1
1 8 17 1 active sync /dev/sdb1
A potom prosím podívej na tohle:
sudo mdadm --query --detail /dev/md0Z toho je vidět, že na md1 se podílí oba disky, na md0 se podílí jen sda! Přitom smartmontools hlásí chyby pro sda, ne pro sdb.
/dev/md0:
Version : 00.90
Creation Time : Sat Dec 20 20:01:05 2008
Raid Level : raid1
Array Size : 975587200 (930.39 GiB 999.00 GB)
Used Dev Size : 975587200 (930.39 GiB 999.00 GB)
Raid Devices : 2
Total Devices : 1
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Sun Sep 6 14:24:36 2009
State : active, degraded
Active Devices : 1
Working Devices : 1
Failed Devices : 0
Spare Devices : 0
UUID : 48d95eb0:844b56ac:37e44c7c:17054917
Events : 0.1545647
Number Major Minor RaidDevice State
0 8 2 0 active sync /dev/sda2
1 0 0 1 removed
Jde mi z toho hlava kolem. Teď dělám dlouhý smart test pro sda. Máš nějaké další tipy? Pochybuju, že jsem ručně odebral sdb2 z md0 :/
Bohužel nevím, jak by měl vypadat výstup z /proc/mdstat, ale předpokládám, že by u md0 i md1 měly být uvedeny oba disky (tedy ne jen sda). Je to tak?Jo.
Jde mi z toho hlava kolem. Teď dělám dlouhý smart test pro sda. Máš nějaké další tipy?Nic víc, než je níže.
Zajímavé je také, že sdb má o (7970 - 7550) / 24 = 17.5 dne menší SpinUp čas, ačkoliv PowerOn čas je prakticky stejný. Že by jej systém už někdy předtím odpojil celý (teď ne, to by sdb2 nebyl aktivní) ?
vsiml sis, ze z md0 je vypadl sdb2 a nikoliv sda2? pro jisotu jeste mrkni na mdadm --detail /dev/md0
ad 2/ udelej zalohu dat!
ad 4/ disk do pole pridas: mdadm /dev/md0 -add /dev/neco
Ahoj. Děkuju za odpověď.
Právě mi dlouhý test běží. Kde najde výsledek? V jakém logu? :) Díky.
Kabel mám náhradní bohužel jen jeden, zkusím tedy vyměnit ten k sda. Zvláštní ale je, že se mi teď ty I/O chyby vůbec nevypisují. Zato předtím se mi jich vypsalo až až...
Hm, smartctl výstup /dev/sda vypadá to spíš na chyby přenosu mezi diskem a řadičem na MB (i když hodnota "Hardware_ECC_Recovered" u sda je víc než podivná). Souhlasí, že ty disky běží cca třičtvrtě roku? Asi bych zkusil očistit kontakty, vyměnit datový kabel, otestovat jej v jiném stroji.
Každopádně, podle mdstat, je /dev/md1 aktivní a synchronizované, ale v /dev/md0 systém používá jen /dev/sda2 - takže /dev/sdb2 z nějakého důvodu deaktivoval, podrobnosti najdete ve "/var/log/messages" - možná se mu při startu zdál sda2 "čerstvější", třeba projet log. Situace tedy vypadá tak, že md0 běží degradované a s diskem, který se zdá blbne.
1) něco se děje, jestli je to disk nebo něco jiného se asi na 100% říci nedá
2) o data byste přijít neměl, chyby mirrorovány nebudou.
3) zjistěte, jak dlouho je md0 rozpadlý, jak důležitá data se tam od té doby mohla změnit a podle toho se musíte rozhodnout
4) ručně, "mdadm /dev/md0 -add /dev/PARTIŠNAVYMĚNĚNÉHODISKU
Co říká "hdparm -I" ?
Ahoj Franto. Díky za odpověď. (nevadí tykání? :))
Disky by mohly být cca 3/4 roku staré, jedou v tom serveru téměř 24 hodin denně. Kabel mám jen jeden, a jak už mi bylo doporučeno, až doběhne test smartmontools, tak zkusím k sda vyměnit.
hdparm -I /dev/sda:
/dev/sda:
ATA device, with non-removable media
Model Number: SAMSUNG HD103UJ
Serial Number: S13PJ9AQC03115
Firmware Revision: 1AA01113
Standards:
Used: ATA-8-ACS revision 3b
Supported: 7 6 5 4
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors: 16514064
LBA user addressable sectors: 268435455
LBA48 user addressable sectors: 1953525168
device size with M = 1024*1024: 953869 MBytes
device size with M = 1000*1000: 1000204 MBytes (1000 GB)
Capabilities:
LBA, IORDY(can be disabled)
Queue depth: 32
Standby timer values: spec'd by Standard, no device specific minimum
R/W multiple sector transfer: Max = 16 Current = 16
Advanced power management level: disabled
Recommended acoustic management value: 254, current value: 0
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 udma7
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=120ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
* SMART feature set
Security Mode feature set
* Power Management feature set
* Write cache
* Look-ahead
* Host Protected Area feature set
* WRITE_BUFFER command
* READ_BUFFER command
* NOP cmd
* DOWNLOAD_MICROCODE
Advanced Power Management feature set
Power-Up In Standby feature set
* SET_FEATURES required to spinup after power up
SET_MAX security extension
Automatic Acoustic Management feature set
* 48-bit Address feature set
* Device Configuration Overlay feature set
* Mandatory FLUSH_CACHE
* FLUSH_CACHE_EXT
* SMART error logging
* SMART self-test
Media Card Pass-Through
* General Purpose Logging feature set
* 64-bit World wide name
* WRITE_UNCORRECTABLE_EXT command
* {READ,WRITE}_DMA_EXT_GPL commands
* Segmented DOWNLOAD_MICROCODE
* SATA-I signaling speed (1.5Gb/s)
* SATA-II signaling speed (3.0Gb/s)
* Native Command Queueing (NCQ)
* Host-initiated interface power management
* Phy event counters
* unknown 76[12]
DMA Setup Auto-Activate optimization
Device-initiated interface power management
* Software settings preservation
* SMART Command Transport (SCT) feature set
* SCT Long Sector Access (AC1)
* SCT LBA Segment Access (AC2)
* SCT Error Recovery Control (AC3)
* SCT Features Control (AC4)
* SCT Data Tables (AC5)
Security:
Master password revision code = 65534
supported
not enabled
not locked
frozen
not expired: security count
supported: enhanced erase
170min for SECURITY ERASE UNIT. 170min for ENHANCED SECURITY ERASE UNIT.
Logical Unit WWN Device Identifier: 5000f0060c1351
NAA : 5
IEEE OUI : f0
Unique ID : 060c1351
Checksum: correct
hdparm -I /dev/sdb:
/dev/sdb:
ATA device, with non-removable media
Model Number: SAMSUNG HD103UJ
Serial Number: S13PJ9AQC03116
Firmware Revision: 1AA01113
Standards:
Used: ATA-8-ACS revision 3b
Supported: 7 6 5 4
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors: 16514064
LBA user addressable sectors: 268435455
LBA48 user addressable sectors: 1953525168
device size with M = 1024*1024: 953869 MBytes
device size with M = 1000*1000: 1000204 MBytes (1000 GB)
Capabilities:
LBA, IORDY(can be disabled)
Queue depth: 32
Standby timer values: spec'd by Standard, no device specific minimum
R/W multiple sector transfer: Max = 16 Current = 16
Advanced power management level: disabled
Recommended acoustic management value: 254, current value: 0
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 udma7
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=120ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
* SMART feature set
Security Mode feature set
* Power Management feature set
* Write cache
* Look-ahead
* Host Protected Area feature set
* WRITE_BUFFER command
* READ_BUFFER command
* NOP cmd
* DOWNLOAD_MICROCODE
Advanced Power Management feature set
Power-Up In Standby feature set
* SET_FEATURES required to spinup after power up
SET_MAX security extension
Automatic Acoustic Management feature set
* 48-bit Address feature set
* Device Configuration Overlay feature set
* Mandatory FLUSH_CACHE
* FLUSH_CACHE_EXT
* SMART error logging
* SMART self-test
Media Card Pass-Through
* General Purpose Logging feature set
* 64-bit World wide name
* WRITE_UNCORRECTABLE_EXT command
* {READ,WRITE}_DMA_EXT_GPL commands
* Segmented DOWNLOAD_MICROCODE
* SATA-I signaling speed (1.5Gb/s)
* SATA-II signaling speed (3.0Gb/s)
* Native Command Queueing (NCQ)
* Host-initiated interface power management
* Phy event counters
* unknown 76[12]
DMA Setup Auto-Activate optimization
Device-initiated interface power management
* Software settings preservation
* SMART Command Transport (SCT) feature set
* SCT Long Sector Access (AC1)
* SCT LBA Segment Access (AC2)
* SCT Error Recovery Control (AC3)
* SCT Features Control (AC4)
* SCT Data Tables (AC5)
Security:
Master password revision code = 65534
supported
not enabled
not locked
frozen
not expired: security count
supported: enhanced erase
176min for SECURITY ERASE UNIT. 176min for ENHANCED SECURITY ERASE UNIT.
Logical Unit WWN Device Identifier: 5000f0060c1361
NAA : 5
IEEE OUI : f0
Unique ID : 060c1361
Checksum: correct
Oba se mi zdají stejné. Chytrý z toho opět bohužel nejsem.
Co kdybych zkusil přidat do md0 znova ten sdb, resync, pak zkusil ty disky znova projet smartctl a pokud by některý hlásil chyby, tak s klidným svědomím vyměnil?
OK, jasně.
Ta nastavení jsou u obou stejná.
Než přidáš ten sdb2, stejně bych nejdřív mrknul do logu, proč jej OS vyfakoval, aby nebyl v horším stavu než ten sda. Jestli je na sdb1 swapák, tak md1 může být OK i proto, že se na něj (téměř) nic nezapisuje. Teoreticky v tom může mít pracky třeba i zdroj (když už jsou vzpomenuté MB, disk, kšandy), proto i otestování v jiném stroji může něco napovědět.
Jestliže je sdb2 offline, tak bych nejdříve otestoval ten, pak sdb2 fsck, na podívání jej montovat readonly. Nemá cenu něco uspěchat, data bývaj cennější než pár minut času.
Teď koukám na /var/log/messages.0
Nejstarší zprávy, které by se mohly tohoto týkat, by mohly být:
Aug 28 17:37:18 junior kernel: [ 5.685755] Driver 'sd' needs updating - please use bus_type methods
Aug 28 17:37:18 junior kernel: [ 5.686035] sd 2:0:0:0: [sda] 1953525168 512-byte hardware sectors (1000205 MB)
Aug 28 17:37:18 junior kernel: [ 5.686098] sd 2:0:0:0: [sda] Write Protect is off
Aug 28 17:37:18 junior kernel: [ 5.686214] sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Aug 28 17:37:18 junior kernel: [ 5.686430] sd 2:0:0:0: [sda] 1953525168 512-byte hardware sectors (1000205 MB)
Aug 28 17:37:18 junior kernel: [ 5.686490] sd 2:0:0:0: [sda] Write Protect is off
Aug 28 17:37:18 junior kernel: [ 5.686605] sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Aug 28 17:37:18 junior kernel: [ 5.686619] sda: sda1 sda2
Aug 28 17:37:18 junior kernel: [ 5.702036] sd 2:0:0:0: [sda] Attached SCSI disk
Aug 28 17:37:18 junior kernel: [ 5.702225] sd 3:0:0:0: [sdb] 1953525168 512-byte hardware sectors (1000205 MB)
Aug 28 17:37:18 junior kernel: [ 5.702277] sd 3:0:0:0: [sdb] Write Protect is off
Aug 28 17:37:18 junior kernel: [ 5.702372] sd 3:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Aug 28 17:37:18 junior kernel: [ 5.702525] sd 3:0:0:0: [sdb] 1953525168 512-byte hardware sectors (1000205 MB)
Aug 28 17:37:18 junior kernel: [ 5.702574] sd 3:0:0:0: [sdb] Write Protect is off
Aug 28 17:37:18 junior kernel: [ 5.702669] sd 3:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Aug 28 17:37:18 junior kernel: [ 5.702679] sdb: sdb1 sdb2
Aug 28 17:37:18 junior kernel: [ 5.706279] sd 3:0:0:0: [sdb] Attached SCSI disk
Aug 28 17:37:18 junior kernel: [ 5.905934] md: md1 stopped.
Aug 28 17:37:18 junior kernel: [ 5.913968] md: bind<sdb1>
Aug 28 17:37:18 junior kernel: [ 5.915669] md: md0 stopped.
Aug 28 17:37:18 junior kernel: [ 5.936680] md: bind<sdb2>
Aug 28 17:37:18 junior kernel: [ 5.970445] md: md1 stopped.
Aug 28 17:37:18 junior kernel: [ 5.970469] md: unbind<sdb1>
Aug 28 17:37:18 junior kernel: [ 5.976346] md: export_rdev(sdb1)
Aug 28 17:37:18 junior kernel: [ 5.997228] md: bind<sdb1>
Aug 28 17:37:18 junior kernel: [ 5.997445] md: bind<sda1>
Aug 28 17:37:18 junior kernel: [ 6.025640] raid1: raid set md1 active with 2 out of 2 mirrors
Aug 28 17:37:18 junior kernel: [ 6.025849] md: md0 stopped.
Aug 28 17:37:18 junior kernel: [ 6.025867] md: unbind<sdb2>
Aug 28 17:37:18 junior kernel: [ 6.027336] md: export_rdev(sdb2)
Aug 28 17:37:18 junior kernel: [ 6.050468] md: bind<sdb2>
Aug 28 17:37:18 junior kernel: [ 6.050732] md: bind<sda2>
Aug 28 17:37:18 junior kernel: [ 6.050799] md: kicking non-fresh sdb2 from array!
Aug 28 17:37:18 junior kernel: [ 6.050816] md: unbind<sdb2>
Aug 28 17:37:18 junior kernel: [ 6.063495] md: export_rdev(sdb2)
Aug 28 17:37:18 junior kernel: [ 6.089617] raid1: raid set md0 active with 1 out of 2 mirrors
Aug 28 17:37:18 junior kernel: [ 6.204081] PM: Starting manual resume from disk
Aug 28 17:37:18 junior kernel: [ 6.262765] EXT3-fs: INFO: recovery required on readonly filesystem.
Aug 28 17:37:18 junior kernel: [ 6.262774] EXT3-fs: write access will be enabled during recovery.
Aug 28 17:37:18 junior kernel: [ 6.376186] kjournald starting. Commit interval 5 seconds
Takže jsem si toho býval mohl všimnout možná už dříve než 28. srpna. Dřívější logy nemám (nebo je nevidím?). Každopádně to by mohlo vysvětlovat těch 17 dní rozdílu v hodnotě spinup. Nicméně to nevysvětluje, proč mi celou dobu počítač šlapal i s jedním diskem, ale teď mi hlásil už podruhé ty I/O chyby.
Asi máš rotování logů po týdnu. Pokud by byly starší, jmenovaly by se /var/log/messages.N (větší N == starší log), počet je dán nastavením logrotate.
Nicméně tohle znamená jen, že ten sdb2 už musel padnout (proč?) někdy před tímhle restartem. S tím testem sdb bych začal, sda se sice chová divně, ale na bezprostřední pád to nevypadá. A o stavu sdb je třeba se dozvědět více, SMART diagnostice důvěřuj, ale prověřuj ;)). Už jsem několikrát zažil, že u disku byly ve SMART datech nesmysly, nebo byl SMART vypnutý a neindikoval nic (ale to asi není tenhle případ).
Tak právě doběhnul smartctl a shodou náhod jsem to omylem spustil nad sdb. Test vyšel bez chyb.
Rotaci logů mám, ale jen po .0, starší nejsou :( Dá se to někde jednoduše nastavit?
Teď asi zkusím ručně přidat tu sdb2 do md0. A uvidíme.
OK.
Nastavení rotace mám ve Fedoře v "/etc/logrotate.conf", možno upravit, tohle je default:
# rotate log files weekly
weekly
# keep 4 weeks worth of backlogs
rotate 4
Díky, logování už jsem našel, mám to tam taky tak, jen jsem si nevšiml, že je to balené. Našel jsem 5. srpna, nicméně stejný problém (minimálně měsíc jsem si toho nevšiml!).
Tak teď sdb2 přidávám, resynchronizuje se obsah md0 z sda2 na sdb2. Vzhledem k tomu, jak je to velký disk, tak to bude trvat víc jak 3 hodiny.
Myslím si, že problém byl způsoben následovně::
Doufám, že synchronizace dojede v pořádku a že se nepřenesou nějaká poškozená data. Každopádně pak nechám spuštěný dlouhý smartctl test nad sda a pokud bude reportovat chyby, budu ho reklamovat.
Ozvu se po synchronizaci a testování sda s výsledkem.
Takže dnes jsem se probudil s kompletní hotovou synchronizací a testem sda.
Synchronizace proběhla v pořádku. Smartctl pro sdb nehlásilo chyby ani před resynchronizací, sda jsem jel přes noc. A chyby také žádné. Test proběhl v pořádku. Pořád mě ale znervózňují ty chyby, které jsem objevil už v začátku. Výpis chyb sda je zde:
smartctl version 5.38 [i686-pc-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/
=== START OF INFORMATION SECTION ===
Device Model: SAMSUNG HD103UJ
Serial Number: S13PJ9AQC03115
Firmware Version: 1AA01113
User Capacity: 1 000 204 886 016 bytes
Device is: In smartctl database [for details use: -P show]
ATA Version is: 8
ATA Standard is: ATA-8-ACS revision 3b
Local Time is: Mon Sep 7 08:15:45 2009 CEST
==> WARNING: May need -F samsung or -F samsung2 enabled; see manual for details.
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x00) Offline data collection activity
was never started.
Auto Offline Data Collection: Disabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: (11471) seconds.
Offline data collection
capabilities: (0x7b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 192) minutes.
Conveyance self-test routine
recommended polling time: ( 21) minutes.
SCT capabilities: (0x003f) SCT Status supported.
SCT Feature Control supported.
SCT Data Table supported.
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000f 100 100 051 Pre-fail Always - 0
3 Spin_Up_Time 0x0007 076 076 011 Pre-fail Always - 8040
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 54
5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0
7 Seek_Error_Rate 0x000f 253 253 051 Pre-fail Always - 0
8 Seek_Time_Performance 0x0025 100 100 015 Pre-fail Offline - 10055
9 Power_On_Hours 0x0032 099 099 000 Old_age Always - 6223
10 Spin_Retry_Count 0x0033 100 100 051 Pre-fail Always - 0
11 Calibration_Retry_Count 0x0012 100 100 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 54
13 Read_Soft_Error_Rate 0x000e 100 100 000 Old_age Always - 0
183 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 6
184 Unknown_Attribute 0x0033 098 098 000 Pre-fail Always - 2
187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0
188 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 0
190 Airflow_Temperature_Cel 0x0022 075 059 000 Old_age Always - 25 (Lifetime Min/Max 25/28)
194 Temperature_Celsius 0x0022 075 058 000 Old_age Always - 25 (Lifetime Min/Max 25/29)
195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 98013428
196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0
197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0030 100 100 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x003e 100 100 000 Old_age Always - 148
200 Multi_Zone_Error_Rate 0x000a 100 100 000 Old_age Always - 0
201 Soft_Read_Error_Rate 0x000a 100 100 000 Old_age Always - 0
SMART Error Log Version: 1
ATA Error Count: 6 (device log contains only the most recent five errors)
CR = Command Register [HEX]
FR = Features Register [HEX]
SC = Sector Count Register [HEX]
SN = Sector Number Register [HEX]
CL = Cylinder Low Register [HEX]
CH = Cylinder High Register [HEX]
DH = Device/Head Register [HEX]
DC = Device Command Register [HEX]
ER = Error register [HEX]
ST = Status register [HEX]
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.
Error 6 occurred at disk power-on lifetime: 0 hours (0 days + 0 hours)
When the command that caused the error occurred, the device was active or idle.
After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
84 51 3f eb 3d 8f e7 Error: ICRC, ABRT 63 sectors at LBA = 0x078f3deb = 126828011
Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
-- -- -- -- -- -- -- -- ---------------- --------------------
c8 00 00 2a 3d 8f e7 08 23:25:57.110 READ DMA
c8 00 00 2a 3c 8f e7 08 23:25:57.090 READ DMA
c8 00 00 2a 3b 8f e7 08 23:25:57.070 READ DMA
c8 00 00 2a 3a 8f e7 08 23:25:57.050 READ DMA
c8 00 00 2a 39 8f e7 08 23:25:57.030 READ DMA
Error 5 occurred at disk power-on lifetime: 0 hours (0 days + 0 hours)
When the command that caused the error occurred, the device was active or idle.
After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
84 51 0f 53 f5 f9 e3 Error: ICRC, ABRT 15 sectors at LBA = 0x03f9f553 = 66712915
Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
-- -- -- -- -- -- -- -- ---------------- --------------------
c8 00 00 62 f4 f9 e3 08 07:24:22.840 READ DMA
c8 00 10 d2 90 0b e4 08 07:24:22.790 READ DMA
c8 00 f8 da 8f 0b e4 08 07:24:22.780 READ DMA
c8 00 00 da 8e 0b e4 08 07:24:22.770 READ DMA
ea 00 00 19 59 70 a0 08 07:24:22.750 FLUSH CACHE EXIT
Error 4 occurred at disk power-on lifetime: 0 hours (0 days + 0 hours)
When the command that caused the error occurred, the device was active or idle.
After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
00 d0 00 00 00 00 a0 at LBA = 0x00000000 = 0
Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
-- -- -- -- -- -- -- -- ---------------- --------------------
ca 00 38 fa 4e 1b ed 08 00:48:39.890 WRITE DMA
ca 00 08 f2 3e 1b ed 08 00:48:39.870 WRITE DMA
ca 00 a0 4a 36 1b ed 08 00:48:39.870 WRITE DMA
ca 00 08 82 24 1b ed 08 00:48:39.810 WRITE DMA
ca 00 00 e2 15 1b ed 08 00:48:39.790 WRITE DMA
Error 3 occurred at disk power-on lifetime: 0 hours (0 days + 0 hours)
When the command that caused the error occurred, the device was active or idle.
After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
04 53 7d 85 6c bf ec Error: ABRT at LBA = 0x0cbf6c85 = 213871749
Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
-- -- -- -- -- -- -- -- ---------------- --------------------
ca 00 a8 5a 6c bf ec 08 6d+21:09:08.620 WRITE DMA
ca 00 08 52 60 bf ec 08 6d+21:09:08.610 WRITE DMA
ca 00 08 ea 3f bf ec 08 6d+21:09:08.550 WRITE DMA
ca 00 08 82 1f bf ec 08 6d+21:09:08.480 WRITE DMA
ca 00 08 1a ff be ec 08 6d+21:09:08.420 WRITE DMA
Error 2 occurred at disk power-on lifetime: 0 hours (0 days + 0 hours)
When the command that caused the error occurred, the device was active or idle.
After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
00 d0 00 00 00 00 a0 at LBA = 0x00000000 = 0
Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
-- -- -- -- -- -- -- -- ---------------- --------------------
ca 00 08 e2 18 87 ec 08 4d+23:10:24.510 WRITE DMA
ca 00 08 1a e4 86 ec 08 4d+23:10:24.460 WRITE DMA
ca 00 d8 a2 c8 86 ec 08 4d+23:10:24.390 WRITE DMA
ca 00 08 9a b4 86 ec 08 4d+23:10:24.370 WRITE DMA
ca 00 50 32 94 86 ec 08 4d+23:10:24.370 WRITE DMA
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Extended offline Completed without error 00% 6216 -
# 2 Extended offline Aborted by host 90% 6208 -
# 3 Short offline Completed without error 00% 6207 -
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.
Mimochodem jsem zkoušel prohodit SATA konektory na desce (takže sda bylo v tu chvíli sdb a opačně) a ten samý disk (sériové číslo má na konci 15) hází po sysctl -a stále těch 6 stejných chyb. Takže by t o dle mého názoru nemuselo být řadičem. Dnes chci koupit úplně nové sata kabely, takže uvidíme.
Byly by tyto chyby podnět k reklamaci a výměně celého disku?
Jo a výpis po synchronizaci vypadá takto:
cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 sdb2[1] sda2[0]
975587200 blocks [2/2] [UU]
md1 : active raid1 sda1[0] sdb1[1]
1172608 blocks [2/2] [UU]
unused devices: <none>
Takže je to snad v pořádku. Stejně si nedokážu vysvětlit, proč ten sdb2 z md0 vypadl...:(
7.9.2009 11:35
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Mimochodem jsem zkoušel prohodit SATA konektory na desce (takže sda bylo v tu chvíli sdb a opačně) a ten samý disk (sériové číslo má na konci 15) hází po sysctl -a stále těch 6 stejných chyb.
Zřejmně smartctl -a. Ty smart chyby si pamatuje disk, tímto prohozením řadič neotestuješ.
A pamatuje si jich právě 6:
ATA Error Count: 6 (device log contains only the most recent five errors)
Jinak, mám úplně stejný disk s 9000 hodinami, můžu poskytnou smartctl statistiky pro porovnání, kdyby jsi měl zájem. Co se týče problému, těch 6 chyb bylo pokaždé na jiném sektoru disku. Kdyby ty sektory byly nečitelné/nezapisovatelné, rozhodně by tyto atributy nebyly nulové:
196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 100 100 000 Old_age Offline - 0
I na základě svých (mám tři bezvadné WD disky s podobnými SATA chybami, všechny jedou po výměně kabelu déle než rok) zkušeností tipuji vadný SATA kabel. Kup co nejlepší (no jak to poznat 
) kabel a pak vyzkoušej badblocks v režimu pro čtení postupně nad oběma disky. Pokud to projde tak buď bez starostí.
Ahoj, díky za odpověď.
Vadný sata kabel by vysvětloval, proč jeden disk jede bez chyb a druhý s chybami, nebo spíš proč ten sda tenkrát zrušil ten OS, když jsem se na něj ani přes SSH nepřipojil....
Jak se pracuje s badblocks? Čtecí režim je bez parametrů? Takže by mělo stačit badblocks /dev/sda resp. badblocks /dev/sdb? Díky!
8.9.2009 14:00
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Ano bez parametrů, můžeš si tam přidat parametr -s ať víš jak dlouho to bude trvat:
root@raid:/#badblocks -s /dev/sde Checking for bad blocks (read-only test): 231808/ 976762584
Výsledek, buď to napíše přímo vadné bloky (čísla sektorů), nebo se ve smartctl -a zvýší hodnota jednoho z těch tří atributů co jsem spal výše. Obojí by bylo na reklamaci disku.
Super, díky. Už to tam jede, cca desetinka procenta za 1 s, takže uvidíme. Zatím bez nového kabelu, jedu to přes ssh z práce :)
Houbelec, je to setinka za vteřinu, tak si asi pěkně počkám. Ale což...z předchozích akcí jsem zvyklý :)
8.9.2009 14:40
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Tak badblocks nevyhodil žádné chyby, a to ani u těch třech hodnot, cos posílal. A to jsem ještě ani nestihl vyměnit ten kabel.
Stejně mě ale znervózňují ty zprávy, které se stále dokola vypisují na obrazovku i do kern.log:
Sep 9 01:22:36 junior kernel: [202133.756057] ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Sep 9 01:22:46 junior kernel: [202133.756111] ata3.00: cmd 35/00:00:7a:52:af/00:04:10:00:00/e0 tag 0 dma 524288 out
Sep 9 01:22:46 junior kernel: [202133.756116] res 40/00:0f:71:89:9b/84:00:40:00:00/e0 Emask 0x4 (timeout)
Sep 9 01:22:46 junior kernel: [202133.756204] ata3.00: status: { DRDY }
Sep 9 01:22:46 junior kernel: [202138.796026] ata3: link is slow to respond, please be patient (ready=0)
Sep 9 01:22:46 junior kernel: [202143.780026] ata3: device not ready (errno=-16), forcing hardreset
Sep 9 01:22:46 junior kernel: [202143.780045] ata3: soft resetting link
Sep 9 01:22:46 junior kernel: [202143.952364] ata3.00: configured for UDMA/133
Sep 9 01:22:46 junior kernel: [202143.952392] ata3: EH complete
Sep 9 01:22:46 junior kernel: [202143.957589] sd 2:0:0:0: [sda] 1953525168 512-byte hardware sectors (1000205 MB)
Sep 9 01:22:46 junior kernel: [202143.958952] sd 2:0:0:0: [sda] Write Protect is off
Sep 9 01:22:46 junior kernel: [202143.958962] sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00
Sep 9 01:22:46 junior kernel: [202143.970257] sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Ahoj všem...tak jsem zpět s prosbou o radu. Výměna kabelů nepomohla.
Koupil jsem 2 nové sata kabely a po spuštění počítače jsem zjistil, že nedetekuje žádné disky. Takže jsem tam jeden nový nechal a druhý vyměnil za starý a hle - ono to jelo...(mimochodem teď tam mám asi 6 sata kabelů a různě jsem je kombinoval)...nicméně chyby to hlásí pořád:
[ 84.446950] ata4.00: cmd 35/00:80:12:4e:8a/00:02:02:00:00/e0 tag 0 dma 327680 out
[ 84.446955] res 51/04:80:12:50:8a/04:00:02:00:00/e0 Emask 0x21 (host bus error)
[ 84.447091] ata4.00: status: { DRDY ERR }
[ 84.447144] ata4.00: error: { ABRT }
[ 84.621152] ata4.00: configured for UDMA/133
[ 84.621178] ata4: EH complete
[ 84.625042] sd 3:0:0:0: [sdb] 1953525168 512-byte hardware sectors (1000205 MB)
Už mě nic nenapadá - nemůže to být deskou? Díky za nápady.
Tak jsem si to cele přečetl. Na zakladě mnohaletých zkušeností s linuxovými sw raidy doporučuju:
a) často a pravidelně (=denně) kontrolovat, že raid se nerozpadl. Pokud se občas (rozhodně ne castěji než jednou za čtvrt roku) rozpadne, nechat zasynchronizovat, bývá to náhodná chyba.
b) pokud se rozpadá častěji, v logu se objevují podivné chyby a případně nejde zasynchronizovat, zjistit příčinu a ihned to opravit (jde o data).
Zásadní otázka: zůstáva závada na stále stejnem: a) disku, b) portu - konektoru řadiče, c) datovém kabelu, ....?
Ve Tvém případě typuji primárně na problém s napájením. A probém po výměně kabelů by mohl vzniknout i tak, že se při tom pohlo i s napajecimi kabely (veškerá elektronika je primárně o vodičích a kontaktech 
. Ale také to mohou být konektory v MB, na disku, zdroji. V podstatě to může být kterákoli komponenta počítače nebo jeho okolí - třeba uvolněný drát do napajecí zásuvky ve zdi Ale to je už věštím z rozbité křišťálové koule (Btv. nemá někdo navíc nějakou lepší?).
Mno, tak jsem si to po sobě přečetl, a nevím jesti to nemám smazat, obávám se, že Tvůj problém to přímo neřeší Prostě jen měnit komponentu po komponentě a sledovat co se děje.
Rozhodně díky za jakoukoliv radu. Na komponenty se chystám tento víkend, ikdyž vím, že to bude hrozně zdlouhavé.
Mimochodem zdroj by to mohl být. Před nedávnem mi odešel PicoPSU adaptér, tak jsem ho "provizorně" nahradil klasickým napájecím zdrojem - samozřejmě tam už zůstal. Ale bylo by mi divné, že když to utáhl 60W zdroj, tak že by to 300 W neutáhl. Odborník (bratr) mi potvrdil, že napětí v jednotlivých větvích je i s tímto provizorním zdrojem zajištěno. Takže nevím.
Teď se zrovna synchronizuje, protože přes noc proběhl kernel panic a to vyžadovalo tvrdý restart.Jinak to od minula drželo.
A k těm tvým otázkám: a) nevím, disky se zdají podle testů smartctl v pořádku, b) zkoušel jsem je nedávno prohazovat a chyby stále stejné, c) různě jsem je kombinoval (nové kabely, nový-starý, nový-jiný starý atp.) a zjistil jsem, že 2 nové kabely nejedou (neproběhne detekce disků při zavádění), což mě trochu znepokojuje. Fakt nechápu :-O
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
6.9.2009 13:04