softraid 5 issue

[Apache]

Hallo,

Ik heb al een tijd een raid 5 array draaien met 6 1TB schijven. Deze deed het op zich zeer goed tot 2 weken geleden. Toen begon één van de schijven read-errors te geven in kern.log. Geen probleem, nieuwe schijven besteld, die schijf als faulty, server af, nieuwe schijf erin, toevoegen, laten resyncen en klaar.

Daar was ik gisteren, alles werkte weer perfect.

Maaar omdat ik dan toch schijven aan het bestellen was heb ik er meteen wat extra besteld en was van plan om de array te grow'n tot 8 disks van 1TB. Nu goed, alles werkte dus server terug af, schijven erin, en gaan.

De originele disks waren sda tem sdf, nu werden de neiuwe ertussen geplugged en die werden sdd en sdh
op zich nog steeds geen probleem mdadm herkent dit.

En met de nieuwe schijven geinstalleerd is de raid 5 array nog steeds benaderbaar. Ik partitioneer de nieuwe disks, ik voeg ze toe aan de array, alles goed en wel. Hij toont 2 spares met mdadm --detail /dev/md0, ik grow het aantal devices naar 8 en hij begint te syncen.

Ik zie dat de snelheid laag is met een cat /proc/mdstat, zo rond de 5MB, dus ik check kern.log. Jawel, de schijf op ata7 geeft ook fouten, goed, dat zal één van de nieuwe disks zijn die niet helemaal koosjer is, ik zet hem wel even op faulty.

Nu hier is het fout gegaan! Ik ga ervanuit dat het een nieuwe disk is, 8 disks, begint vast bij ata0, dus ata7 is sdh ... niet dus, ik gooi /dev/sdh op faulty en mdadm gooit /dev/sde (blijkbaar de schijf die ECHT fouten gaf) op faulty, maw 2 faulty disks (waarvan slechts één écht faulty), kan niet meer resyncen ...

Tijdens het booten geeft hij aan: not enough disks to rebuild array, en als hij volledig booted is is er geen /dev/md0 momenteel!!

Pijnlijke situatie dus ... een redelijk specifiek geval, ik hoop op éénder welk advies of plan van aanpak die jullie mij kunnen geven.
Verder heb ik nog 2TB disks als spare gekocht, dus ik kan wel redeiljk creatief zijn met tijdelijk nog extra spare's te adden, hiervoor heb ik natuurlijk /dev/md0 nodig ...

Ik heb zelf deze "oplossing" verzonnen en daar had ik ook graag jullie mening over:
Aangezien het adden van de nieuwe disks < 1% was, veronderstel ik dat mijn originele 6 disks nog zo goed als onaangeroerd zijn.
Kan ik in /etc/mdadm.conf de raid array ipv te laten scannen niet op de 6 devices specifieren en dat hij zo "hardcoded" terug met die 6 disks aan de slag kan? Goed er is mss wat dataloss (die 1%) die hij misschien kan resyncen? Of met een fsck op te lossen valt.

Ik probeer niet het dataverlies volledig te voorkomen ik probeer het te beperken, elke hulp hierbij word ten zeerste geapprecieerd!
Mochten jullie linux soft raid guru's kennen, aarzel dan niet om ze naar deze thread te sturen aub, alvast bedankt!

[tormentor1985]

Wat nou als je de 'nieuwe' schijven loskoppelt en het systeem boot met alleen de 'oude' disks, herkent het systeem de array dan wel? Alhoewel ik zelf denk van niet aangezien het systeem al aan het resyncen was. Daarom vind ik het ook niet handig dat je tijdens het resyncen een disk uit je array trekt. Dat is natuurlijk vragen om problemen

Verders, zorg altijd voor een off-line backup ik kies voor mezelf ook altijd voor raid-5 met daarnaast een aantal externe hard disks voor de backup die ik bij m'n schoonouders aan de overkant neer leg.

[Pantagruel]

Welke ver van mdadm (ivm ondersteunde command switches)??

Probeer eens de volgende commando's (su/sudo/root):

mdadm --detail /dev/md0
als output is: md device /dev/md0 does not appear to be active, oeps.

mdadm --examine /dev/md0
als output is: No md superblock detected on /dev/md0, oeps.

mdadm --assemble /dev/md0
als output is: no devices found for /dev/md0,oeps.

Bij oeps, is t nog steeds goed mogelijk dat de RAID array nog intact is, maar enkel samengevoegd "assembled" moet worden.

mdadm --assemble /dev/md0 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sd..

Vervolgens zal cat /proc/mdstat de rebuild status geven (kan lang duren)

Daarna kan t zijn dat je je array niet kunt expanderen omdat een "grow" de /etc/mdadm.conf file niet aanpast. Om deze bij te werken run: mdadm --detail --scan >> /etc/mdadm.conf

Doe vervolgens een vi /etc/mdadm.conf om oude meuk uit je mdadm.conf te verwijderen

[Apache]

Als het goed is heb ik: Package: mdadm (2.6.7.2-3)
standaard versie van debian 5.0

De eerste 3 werken al zeker niet niet, die heb ik getest, het zal dus die laatste worden.

Ik ben van plan die uit te voeren met de 6 originele disks, de configuratie waarvan ik zeker weet dat deze werkt, lijkt dit jou ook het beste?

Verder weet ik dat de rebuild lang duurt, ik heb een via c7 cpu, dit duurt ongeveer 900 minuten ... daarom heb ik ook besloten om wat snellere hw te bestellen voor het leven met software raid wat aangenamer te maken.

alvast bedankt, ik post vanavond de resultaten bij gebrek aan toegang tot mijn server.

[Verwijderd]

Je zou ook het volgende kunnen proberen:

echo "clean" > /sys/block/md0/md/array_state

Zie ook de diverse posts in dit topic:

http://www.linuxquestions...ot-ron-or-rebuild-505361/

[Tomsworld]

Anders even posten op de linux-raid mailing list, de Neil, de auteur van sw raid md zit daar en vrij hulpvaardig voor zo'n problemen. Vaak heb je heel snel een concrete oplossing. Er zijn recentelijk een paar bugs geweest ivm rebuild dacht ik.

[Pantagruel]

Apache schreef op dinsdag 30 juni 2009 @ 09:53:
Als het goed is heb ik: Package: mdadm (2.6.7.2-3)
standaard versie van debian 5.0

De eerste 3 werken al zeker niet niet, die heb ik getest, het zal dus die laatste worden.

Ik ben van plan die uit te voeren met de 6 originele disks, de configuratie waarvan ik zeker weet dat deze werkt, lijkt dit jou ook het beste?

Verder weet ik dat de rebuild lang duurt, ik heb een via c7 cpu, dit duurt ongeveer 900 minuten ... daarom heb ik ook besloten om wat snellere hw te bestellen voor het leven met software raid wat aangenamer te maken.

alvast bedankt, ik post vanavond de resultaten bij gebrek aan toegang tot mijn server.

Inderdaad met de oorspronkelijke 6 disks.

And with ^^ , Neill is altijd zeer behulpzaam.

SW RAID-5 op iets minder snelle hardware is inderdaad een b*tch, is dan voor mij ook de reden geweest om toch een tweedehands hardware raid kaart aan te schaffen (3ware 8500S, 8 x SATA).

[ Voor 0% gewijzigd door Pantagruel op 30-06-2009 11:40 . Reden: 8500S ipv 9500S ]

[gertvdijk]

Niet zozeer nuttig voor het redden van je huidige data, wel een paar dingen voor een volgende keer:

Groot voordeel dat je sw-raid draait is dat je nu eenvoudig ook SMART data kan uitlezen. Ik zou daarom even smartmontools installeren en configureren zodat je mailtjes krijgt bij schijven die doodgaan.

Verder moet je *nooit* met twee schijven tegelijk een RAID5 array gaan growen, dat heb je nu wel geleerd. Immers, je hebt maar 1 parity disk (distributed - 1 is eigenlijk veel te weinig op zoveel schijven, ik zou RAID6 gepakt hebben) en als er wat mis gaat bij het rebuilden ben je de sjaak. Met twee nieuwe schijven, een zeer I/O intensief proces en de lange duur is die kans alleen maar groter... Als je eerst 1 schijf had toegevoegd en deze of een andere had gefaald dan kon het growen namelijk wel doorgaan in degraded mode.

Verder, uit de manpage van mdadm

       When relocating the first few stripes on a raid5, it is not possible to
       keep  the  data on disk completely consistent and crash-proof.  To pro‐
       vide the required safety, mdadm disables writes to the array while this
       "critical  section" is reshaped, and takes a backup of the data that is
       in that section.  This backup is normally stored in any  spare  devices
       that  the  array  has, however it can also be stored in a separate file
       specified with the --backup-file option.  If this option is  used,  and
       the system does crash during the critical period, the same file must be
       passed to --assemble to restore the backup and reassemble the array.

[ Voor 45% gewijzigd door gertvdijk op 30-06-2009 11:24 ]

[lamko]

Ik heb de inhoud van de superblocks verwijderd en ben gewoon opnieuw begonnen.
Mdadm herkend je data zodat je niks kwijtraakt. Waar je natuurlijk wel op moet letten is dat je het op dezelfde manier weer aanmaakt.

[Apache]

Goed, ik heb net wat kunnen testen, hier de resultaten:

Hier de schijven met zoals je duidelijk kan zien een nieuwe /dev/sdd omdat de vorige faalde, deze config HEEFT geresync, en was in orde voor ik probeerde te grow'n, dus daar ben ik mee van plan om mee verder te gaan.

code:

bbox:~# lsscsi
[0:0:0:0]    disk    ATA      WDC WD10EACS-00D 01.0  /dev/sda
[1:0:0:0]    disk    ATA      WDC WD10EACS-00D 01.0  /dev/sdb
[2:0:0:0]    disk    ATA      WDC WD10EACS-00D 01.0  /dev/sdc
[4:0:0:0]    disk    ATA      WDC WD10EACS-65D 01.0  /dev/sdd
[5:0:0:0]    disk    ATA      WDC WD10EACS-00D 01.0  /dev/sde
[6:0:0:0]    disk    ATA      WDC WD10EACS-00D 01.0  /dev/sdf

Ik check de smart statusses:

code:

bbox:~# smartctl -H /dev/sda
smartctl version 5.38 [i686-pc-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

bbox:~# smartctl -H /dev/sdb
smartctl version 5.38 [i686-pc-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

bbox:~# smartctl -H /dev/sdc
smartctl version 5.38 [i686-pc-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

bbox:~# smartctl -H /dev/sdd
smartctl version 5.38 [i686-pc-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: FAILED!
Drive failure expected in less than 24 hours. SAVE ALL DATA.
Failed Attributes:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   139   139   140    Pre-fail  Always   FAILING_NOW 487

bbox:~# smartctl -H /dev/sde
smartctl version 5.38 [i686-pc-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

bbox:~# smartctl -H /dev/sdf
smartctl version 5.38 [i686-pc-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

Met andere woorden mijn replacement disk is ook al aan het failen??? Misschien was het deze wel die door de grow operation op faulty werd gezet.

goed, die disk moet het maar zo lang overleven tot mijn data terug beschikbaar is, daarna kan ik hem snel vervangen.

code:

mdadm --zero-superblock /dev/sda1
mdadm --zero-superblock /dev/sdb1
mdadm --zero-superblock /dev/sdc1
mdadm --zero-superblock /dev/sdd1
mdadm --zero-superblock /dev/sde1
mdadm --zero-superblock /dev/sdf1

code:

gevolgd door:
mdadm --create --verbose /dev/md0 --level=5 --raid-devices=6 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1

Ik ben 99% zeker dat ik deze volgorde heb aangehouden toen ik de array initieel creeërde. Ik heb nog wel dit van VOOR de "crash":

code:

bbox:/home/blacky# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 sdd1[6] sda1[0] sdf1[5] sde1[4] sdc1[2] sdb1[1]
      4883799680 blocks level 5, 64k chunk, algorithm 2 [6/5] [UUU_UU]
      [>....................]  recovery =  0.4% (3996208/976759936) finish=898.2min speed=18047K/sec

unused devices: <none>

bbox:/home/blacky# mdadm --detail /dev/md0
/dev/md0:
        Version : 00.90
  Creation Time : Sat Dec 13 08:30:08 2008
     Raid Level : raid5
     Array Size : 4883799680 (4657.55 GiB 5001.01 GB)
  Used Dev Size : 976759936 (931.51 GiB 1000.20 GB)
   Raid Devices : 6
  Total Devices : 6
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Sun Jun 28 23:25:48 2009
          State : clean, degraded, recovering
 Active Devices : 5
Working Devices : 6
 Failed Devices : 0
  Spare Devices : 1

         Layout : left-symmetric
     Chunk Size : 64K

 Rebuild Status : 0% complete

           UUID : 2ecd246f:8de14b9d:4d948b44:39f918b9 (local to host bbox)
         Events : 0.88

    Number   Major   Minor   RaidDevice State
       0       8        1        0      active sync   /dev/sda1
       1       8       17        1      active sync   /dev/sdb1
       2       8       33        2      active sync   /dev/sdc1
       6       8       49        3      spare rebuilding   /dev/sdd1
       4       8       65        4      active sync   /dev/sde1
       5       8       81        5      active sync   /dev/sdf1

Waarin het rebuilden van de spare bezig is, nu zag ik daar dit:
sdd1[6] sda1[0] sdf1[5] sde1[4] sdc1[2] sdb1[1]

maw er is geen 3 meer, en sdd is nr 6, betekend dat dat ik dit moet doen om de raid array opnieuw aan te maken:

code:

mdadm --create --verbose /dev/md0 --level=5 --raid-devices=6 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sde1 /dev/sdf1 /dev/sdd1

of zoals aangemaakt met de originele disks:

code:

mdadm --create --verbose /dev/md0 --level=5 --raid-devices=6 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1

ik heb alvast beide eens gerunned, daarna natuurlijk niets gedaan en telkens superblocks opnieuw gezero'd, dan krijg ik dit bvb voor de 1ste optie:

code:

bbox:~# mdadm --create --verbose /dev/md0 --level=5 --raid-devices=6 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sde1 /dev/sdf1 /dev/sdd1
mdadm: layout defaults to left-symmetric
mdadm: chunk size defaults to 64K
mdadm: /dev/sda1 appears to contain an ext2fs file system
    size=588832384K  mtime=Mon Jun 29 22:46:09 2009
mdadm: size set to 976759936K
Continue creating array? yes
mdadm: array /dev/md0 started.

In kern.log zie ik dit verschijnen:

code:

Jun 30 20:11:52 bbox kernel: [ 1245.120192] md: bind<sda1>
Jun 30 20:11:53 bbox kernel: [ 1245.595300] md: bind<sdb1>
Jun 30 20:11:53 bbox kernel: [ 1246.097775] md: bind<sdc1>
Jun 30 20:11:54 bbox kernel: [ 1246.593029] md: bind<sde1>
Jun 30 20:11:54 bbox kernel: [ 1247.089113] md: bind<sdf1>
Jun 30 20:11:55 bbox kernel: [ 1247.671174] md: bind<sdd1>
Jun 30 20:11:55 bbox kernel: [ 1247.853664] raid5: device sdf1 operational as raid disk 4
Jun 30 20:11:55 bbox kernel: [ 1247.853732] raid5: device sde1 operational as raid disk 3
Jun 30 20:11:55 bbox kernel: [ 1247.853789] raid5: device sdc1 operational as raid disk 2
Jun 30 20:11:55 bbox kernel: [ 1247.853846] raid5: device sdb1 operational as raid disk 1
Jun 30 20:11:55 bbox kernel: [ 1247.853903] raid5: device sda1 operational as raid disk 0
Jun 30 20:11:55 bbox kernel: [ 1247.855344] raid5: allocated 6305kB for md0
Jun 30 20:11:55 bbox kernel: [ 1247.855410] raid5: raid level 5 set md0 active with 5 out of 6 devices, algorithm 2
Jun 30 20:11:55 bbox kernel: [ 1247.855476] RAID5 conf printout:
Jun 30 20:11:55 bbox kernel: [ 1247.855528]  --- rd:6 wd:5
Jun 30 20:11:55 bbox kernel: [ 1247.855581]  disk 0, o:1, dev:sda1
Jun 30 20:11:55 bbox kernel: [ 1247.855635]  disk 1, o:1, dev:sdb1
Jun 30 20:11:55 bbox kernel: [ 1247.855688]  disk 2, o:1, dev:sdc1
Jun 30 20:11:55 bbox kernel: [ 1247.855741]  disk 3, o:1, dev:sde1
Jun 30 20:11:55 bbox kernel: [ 1247.855794]  disk 4, o:1, dev:sdf1
Jun 30 20:11:55 bbox kernel: [ 1247.856381] md0: detected capacity change from 0 to 5001010872320
Jun 30 20:11:55 bbox kernel: [ 1247.856450]  md0: unknown partition table

In cat /proc/mdstat

code:

bbox:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active (auto-read-only) raid5 sdd1[6](S) sdf1[4] sde1[3] sdc1[2] sdb1[1] sda1[0]
      4883799680 blocks level 5, 64k chunk, algorithm 2 [6/5] [UUUUU_]

unused devices: <none>

En mdadm --detail /dev/md0

code:

bbox:~# mdadm --detail /dev/md0
/dev/md0:
        Version : 00.90
  Creation Time : Tue Jun 30 20:11:52 2009
     Raid Level : raid5
     Array Size : 4883799680 (4657.55 GiB 5001.01 GB)
  Used Dev Size : 976759936 (931.51 GiB 1000.20 GB)
   Raid Devices : 6
  Total Devices : 6
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Tue Jun 30 20:11:52 2009
          State : clean, degraded
 Active Devices : 5
Working Devices : 6
 Failed Devices : 0
  Spare Devices : 1

         Layout : left-symmetric
     Chunk Size : 64K

           UUID : c577e169:9edad62b:4d948b44:39f918b9 (local to host bbox)
         Events : 0.1

    Number   Major   Minor   RaidDevice State
       0       8        1        0      active sync   /dev/sda1
       1       8       17        1      active sync   /dev/sdb1
       2       8       33        2      active sync   /dev/sdc1
       3       8       65        3      active sync   /dev/sde1
       4       8       81        4      active sync   /dev/sdf1
       5       0        0        5      removed

       6       8       49        -      spare   /dev/sdd1

Maw, wilt hij de sdd niet adden omdat die een slechte smart status heeft? Ik laat mij graag door jullie adviseren voor de volgende stap.

* nota, voor de block size & left symmetric layout ben ik zeker dat ik deze defaults heb aangehouden

[Apache]

http://www.spinics.net/lists/raid/msg24005.html

[lamko]

Mdadm leest geen smart uit dus daar ligt het niet aan. ik zou van alle schijven een image maken en raid recovery software er op los laten. Heb je natuurlijk wel wat extra capaciteit nodig !

[Apache]

Lamko, je hebt gelijk, de data is me wel wat waard, dus ik ga een 2e machine bouwen, 6 schijven in raid0 (maakt niet uit als er hier iets mee gebeurd) en zal van de originele schijven een image maken en dan een raid maken van die virtuele images die op de raid 0 array staan

Daar kan ik dan zonder angst om het "erger" te maken experimenteren met data recovery tools, data carving, etc.

De data recoveren is niet zo enorm dringend, t'zou gewoon leuk zijn op een bepaald moment iets van een 80% kunnen terug halen, verder is het een leuk experiment.

Ik zal de vooruitgang van het recovery process hier posten, ik vermoed dat ik in de toekomst ook nog wel wat vragen zal hebben, of als jullie mooie ideeën hebben om wat te recoveren dan hoor ik het wel.

[iBurger]

gertvdijk schreef op dinsdag 30 juni 2009 @ 11:14:
Niet zozeer nuttig voor het redden van je huidige data, wel een paar dingen voor een volgende keer:

Groot voordeel dat je sw-raid draait is dat je nu eenvoudig ook SMART data kan uitlezen. Ik zou daarom even smartmontools installeren en configureren zodat je mailtjes krijgt bij schijven die doodgaan.

Dit artikel van slashdot, is interessant. SMART schijnt niet zo goed te werken als ik altijd dacht. http://hardware.slashdot.org/article.pl?sid=07/02/18/0420247

[Apache]

Ja, die smart is helemaal niet logisch.

1) de eerste disk die ik replacede die in kern.log DRY read errors gaf had een smart state die ok was
2) de nieuwe disk die ik er heb ingestoken om die te vervangen geeft geen errors maar wel slechte smart state

...

kan misschien een indicatie zijn, maar meer ook niet denk ik.