Onderwerp: Probleem met soft-raid1, mdadm blijft loopen ivm "read errors"

Ik heb hier een raar geval, afgelopen nacht was een machine plotseling vastgelopen. Na een reboot middels de APC, is de machine begonnen met het rebuilden van de lokale RAID-1 array.
Na wat zoeken in de logfiles bleek dat er een probleem op /dev/sda is ontstaan (enkele minuten voor de crash):

Code:

Mar 13 00:29:07 server kernel: ata1.00: exception Emask 0x0 SAct 0x7 SErr 0x0 action 0x0
Mar 13 00:29:07 server kernel: ata1.00: irq_stat 0x40000008
Mar 13 00:29:07 server kernel: ata1.00: cmd 60/00:00:33:86:00/01:00:6e:00:00/40 tag 0 ncq 131072 in
Mar 13 00:29:07 server kernel:          res 41/40:00:4d:86:00/c8:00:6e:00:00/40 Emask 0x409 (media error) <F>
Mar 13 00:29:07 server kernel: ata1.00: status: { DRDY ERR }
Mar 13 00:29:07 server kernel: ata1.00: error: { UNC }
Mar 13 00:29:07 server kernel: ata1.00: configured for UDMA/133
Mar 13 00:29:07 server kernel: ata1: EH complete
Mar 13 00:29:11 server kernel: ata1.00: exception Emask 0x0 SAct 0x4 SErr 0x0 action 0x0
Mar 13 00:29:11 server kernel: ata1.00: irq_stat 0x40000008
Mar 13 00:29:11 server kernel: ata1.00: cmd 60/00:10:33:86:00/01:00:6e:00:00/40 tag 2 ncq 131072 in
Mar 13 00:29:11 server kernel:          res 41/40:00:53:86:00/00:00:6e:00:00/40 Emask 0x409 (media error) <F>
Mar 13 00:29:11 server kernel: ata1.00: status: { DRDY ERR }
Mar 13 00:29:19 server kernel: ata1.00: error: { UNC }
Mar 13 00:29:22 server kernel: ata1.00: configured for UDMA/133
Mar 13 00:29:27 server kernel: ata1: EH complete
Mar 13 00:29:30 server kernel: ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x0
Mar 13 00:29:35 server kernel: ata1.00: irq_stat 0x40000008
Mar 13 00:29:39 server kernel: ata1.00: cmd 60/00:00:33:86:00/01:00:6e:00:00/40 tag 0 ncq 131072 in
Mar 13 00:29:43 server kernel:          res 41/40:00:4d:86:00/00:00:6e:00:00/40 Emask 0x409 (media error) <F>
Mar 13 00:29:43 server kernel: ata1.00: status: { DRDY ERR }
Mar 13 00:29:48 server kernel: ata1.00: error: { UNC }
Mar 13 00:29:51 server kernel: ata1.00: configured for UDMA/133
Mar 13 00:29:59 server kernel: ata1: EH complete
Mar 13 00:30:04 server kernel: ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x0
Mar 13 00:30:14 server kernel: ata1.00: irq_stat 0x40000008
Mar 13 00:30:15 server kernel: ata1.00: cmd 60/00:00:33:86:00/01:00:6e:00:00/40 tag 0 ncq 131072 in
Mar 13 00:30:19 server kernel:          res 41/40:00:4d:86:00/00:00:6e:00:00/40 Emask 0x409 (media error) <F>
Mar 13 00:30:23 server kernel: ata1.00: status: { DRDY ERR }
Mar 13 00:30:25 server kernel: ata1.00: error: { UNC }
Mar 13 00:30:31 server kernel: ata1.00: configured for UDMA/133
Mar 13 00:30:31 server kernel: ata1: EH complete
Mar 13 00:30:38 server kernel: ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x0
Mar 13 00:30:39 server kernel: ata1.00: irq_stat 0x40000008
Mar 13 00:30:43 server kernel: ata1.00: cmd 60/00:00:33:86:00/01:00:6e:00:00/40 tag 0 ncq 131072 in
Mar 13 00:30:47 server kernel:          res 41/40:00:4d:86:00/00:00:6e:00:00/40 Emask 0x409 (media error) <F>
Mar 13 00:30:47 server kernel: ata1.00: status: { DRDY ERR }
Mar 13 00:30:49 server kernel: ata1.00: error: { UNC }
Mar 13 00:30:54 server kernel: ata1.00: configured for UDMA/133
Mar 13 00:30:55 server kernel: ata1: EH complete
Mar 13 00:30:55 server kernel: ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x0
Mar 13 00:30:55 server kernel: ata1.00: irq_stat 0x40000008
Mar 13 00:30:55 server kernel: ata1.00: cmd 60/00:00:33:86:00/01:00:6e:00:00/40 tag 0 ncq 131072 in
Mar 13 00:30:56 server kernel:          res 41/40:00:53:86:00/00:00:6e:00:00/40 Emask 0x409 (media error) <F>
Mar 13 00:30:56 server kernel: ata1.00: status: { DRDY ERR }
Mar 13 00:30:56 server kernel: ata1.00: error: { UNC }
Mar 13 00:30:56 server kernel: ata1.00: configured for UDMA/133
Mar 13 00:30:56 server kernel: sd 0:0:0:0: SCSI error: return code = 0x08000002
Mar 13 00:30:56 server kernel: sda: Current [descriptor]: sense key: Medium Error
Mar 13 00:30:56 server kernel:     Add. Sense: Unrecovered read error - auto reallocate failed
Mar 13 00:30:56 server kernel:
Mar 13 00:30:56 server kernel: Descriptor sense data with sense descriptors (in hex):
Mar 13 00:30:56 server kernel:         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00
Mar 13 00:30:56 server kernel:         6e 00 86 53
Mar 13 00:30:56 server kernel: end_request: I/O error, dev sda, sector 1845528147

Tijdens het rebuilden van de array begint het hele zaakje te loopen. Rebuilden gaat prima, tot +/- 80%, daarna begint het verhaal weer helemaal bij 0%.

Code:

md3 : active raid1 sdb4[2] sda4[0]
954622336 blocks [2/1] [U_]
[====>................]  recovery = 21.6% (206643776/954622336) finish=367.3min speed=33936K/sec

De betreffende errors gaan allemaal over "read" errors. Smart info ziet er redelijk schoon uit, geen "reallocated sectors", maar wel een stuk of 40 "Current_Pending_Sector".
Al met al lijken er nog geen bad sectors remapped te zijn.

Normaal gesproken is het natuurlijk "simpel" om even de (mogelijk) rotte schijf (sda) te verwisselen, maar dat gaat in dit geval niet omdat de machine weigert zijn RAID-1 array te rebuilden. Zolang de array niet in orde is, heb ik niet de mogelijkheid om /dev/sda als failed te markeren aangezien /dev/sda op dit moment de enige "active" disk is.

Code:

# mdadm -D /dev/md3
/dev/md3:
        Version : 0.90
  Creation Time : Sun Oct  3 16:43:47 2010
     Raid Level : raid1
     Array Size : 954622336 (910.40 GiB 977.53 GB)
  Used Dev Size : 954622336 (910.40 GiB 977.53 GB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 3
    Persistence : Superblock is persistent


    Update Time : Tue Mar 13 17:13:19 2012
          State : active, degraded, recovering
 Active Devices : 1
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 1


 Rebuild Status : 23% complete


           UUID : ea682742:2847b158:129d617b:7c93e4c5
         Events : 0.31711407


    Number   Major   Minor   RaidDevice State
       0       8        4        0      active sync   /dev/sda4
       2       8       20        1      spare rebuilding   /dev/sdb4

Iemand hier iets vergelijkbaars meegemaakt? Zou er een oplossing zijn de betreffende sectors te skippen, en op deze manier de hele array te kunnen syncen.

Ziet er uit als een rotte disk.
Als je het rebuilden wil stoppen zou je kunnen proberen om
echo "idle" > /sys/block/md3/md/sync_action
uit te voeren.
Dat heeft me in het verleden wel eens gered uit zo'n situatie.

Succes

Je kan sda toch gewoon vervangen en op de nieuwe disk met dd de partitie tabel kopieren en de schijf weer "starten"? Moet volgens mij goed gaan?

Oorspronkelijk geplaatst door Dreas

Je kan sda toch gewoon vervangen en op de nieuwe disk met dd de partitie tabel kopieren en de schijf weer "starten"? Moet volgens mij goed gaan?

Dat is dus juist het lastige.... sdb bevat "oude" data, en wordt in feite gesynced met content op de active (sda) disk. Als sdb het probleem was zou er nu geen probleem zijn, want dan is het een kwestie van disk wisselen en rebuilden.
Het probleem is juist dat sda juist rotte sectors heeft, en daardoor weigert mdadm om sdb te rebuilden.
Zojuist gechecked en het rebuilden stopt bij +/- 94%, iets meer als de 80% welke ik eerst vermelde. Zodra 94% in de buurt komt begint het zooitje weer bij 0%, en blijft eeuwig loopen.

Code:

Mar 14 03:32:40 server smartd[4264]: Device: /dev/sda, FAILED SMART self-check. BACK UP DATA NOW!
Mar 14 03:32:40 server smartd[4264]: Device: /dev/sda, 40 Currently unreadable (pending) sectors

Is iig een samenloop van het e.a.
- Machine crash, enkele minuten later nadat sda reported werd. Voor de crash was de array nog in orde
- Na de reboot is de machine automatisch begonnen het met resyncen van de array, in dit geval sda -> sdb, en laat sda nu net de probleemgevende disk zijn waar alle data op staat.

Al met al vermoed ik dat het een gevalletje gaat worden waarbij een nieuwe array aangemaakt moet worden.

Vanaf een rescue cd: RAID array opnieuw aanmaken met dezelfde opties als oorspronkelijk gebruikt + --assume-clean

Ik volg het niet. sdb is toch de active disk? Die zal gewoon alle data netjes bevatten? sda is stuk gegaan en uit de array gehaald .. die kan je dus vervangen. Als je dan de nieuwe disk opbouwt krijgt die netjes alle recente data van sdb? Waarom zou sdb verouderde data bevatten t.o.v. de defecte sda? Zo werkt raid-1 niet?

Klopt wat Dreas zegt, hoe je het nu schets was je raid1 array al degraded. Disk 0 heeft read errors en word raid1 uitgegooit, raid1 blijft doordraaien met de meest recente data. Althans dit is hoe raid1 normaliter werkt en zou moeten werken, nu heb je wel een crash gehad en kan het zijn dat je controller in de war is, maar eigenlijk kan dat theoretisch ook alleen wanneer je raidset al degraded was.

Disk 1 is gewoon door blijven draaien na de crash en is niet gemarkeerd als kapot.
Daarom staat er nu nog data op disk 1 (sda) die hij naar disk 2 (sdb) wil hebben.

Dat is wat ik er van begrijp?

Indien een server niet netjes is uit gezet kan de inhoud van de 2 schijven wel iets afwijken.
Die hoeven immers niet van hetzelfde merk zijn, en kunnen ook een afwijkende hoeveelheid write cache hebben. Deze wordt -in tegenstelling tot bij sommige hardware RAID kaarten- niet standaard uitgeschakeld.

Daarom heeft de software RAID stack van Linux de vervelende eigenschap om in zo'n geval dan maar alles van schijf 1 naar schijf 2 te kopieeren.
Dat wil niet perse zeggen dat de data op schijf 2 ouder is, het kan ook andersom zijn, maar dat weet mdadm niet.
Die wil er alleen maar voor zorgen dat de data op beide schijven weer exact 100% gelijk is.

Probleem wat nu dus optreed is dat hij hiervoor automatisch schijf 2 als spare heeft gemarkeerd, maar er daarna pas achter is gekomen dat schijf 1 eigenlijk stuk is.
En er is helaas geen eenvoudige optie om te zeggen: markeer schijf 2 als active en markeer schijf 1 als faulted.
Dat kan alleen via omwegen (door bijv. de array eerst opnieuw aan te maken)

Er is geen disk 1 en disk 2 .. er zijn gewoon 2 disks waarvan er 1 toevallig "a" heet en de ander "b". Maar die zijn met RAID-1 exact gelijk aan elkaar. Als er 1 stuk gaat, wordt die uit de raid verwijderd. Dat is in dit geval "a". Als je er een nieuwe "a" in stopt dan wordt die weer opgebouwd net als "b" en moet alle data er gewoon zijn?

Ik heb het idee dat de verwarring is dat "a" een hoofdschijf ofzo zou zijn die daarom recentere data zou bevatten dan "b". Maar dat klopt dus niet, of er moet iets heel raars gebeurd zijn maar dat lijkt me zeer onwaarschijnlijk.

Ok, klinkt alsof maxnet het beter begrijpt dan ik dus zou daar maar naar luisteren Dit is niet sarcastisch bedoeld.

Oorspronkelijk geplaatst door Dreas

Er is geen disk 1 en disk 2 .. er zijn gewoon 2 disks waarvan er 1 toevallig "a" heet en de ander "b". Maar die zijn met RAID-1 exact gelijk aan elkaar. Als er 1 stuk gaat, wordt die uit de raid verwijderd. Dat is in dit geval "a". Als je er een nieuwe "a" in stopt dan wordt die weer opgebouwd net als "b" en moet alle data er gewoon zijn?

Ik heb het idee dat de verwarring is dat "a" een hoofdschijf ofzo zou zijn die daarom recentere data zou bevatten dan "b". Maar dat klopt dus niet, of er moet iets heel raars gebeurd zijn maar dat lijkt me zeer onwaarschijnlijk.

Dreas het is software RAID, geen hardware RAID

Dan heb je gewoon /dev/sda en /dev/sdb op je server en /dev/md0 bijvoorbeeld.

Beetje vreemd verhaal, volgens je rebuild process wordt er van sdb4 naar sda4 data weggeschreven dus zou je sda gewoon moeten kunnen vervangen.

Oorspronkelijk geplaatst door dennis0162

Dreas het is software RAID, geen hardware RAID

Dan heb je gewoon /dev/sda en /dev/sdb op je server en /dev/md0 bijvoorbeeld.

Ja dat begreep ik .. gebruiken het zelf ook zeer regelmatig