Persistentes RAID5 clean, degraded

[lolomat]

Hallo zusammen

Ich hab zurzeit ein LVM RAID5 welches mir Kopfzerbrechen bereitet.

Ausgangslage
4 SATA Festplatten sda-d welche so partitioniert sind:

   Device Boot    Start       End    Blocks   Id  System
/dev/sda1               1          98      787153+  fd  Linux raid autodetect
/dev/sda2              99         147      393592+  fd  Linux raid autodetect
/dev/sda3             165       60801   487066702+  fd  Linux raid autodetect

Disk4 crasht und wird ersetzt, doch beim Einsetzten der neuen Festplatte wird der Kontakt zur Disk2 kurz unterbrochen.

Der Superblock ist persistent und die Daten nicht wirklich inkonsistent also:

cube> mdadm --assemble --force -v /dev/md2 /dev/sda3 /dev/sdb3 /dev/sdc3
mdadm: looking for devices for /dev/md2
mdadm: /dev/sda3 is identified as a member of /dev/md2, slot 0.
mdadm: /dev/sdb3 is identified as a member of /dev/md2, slot 1.
mdadm: /dev/sdc3 is identified as a member of /dev/md2, slot 2.
mdadm: clearing FAULTY flag for device 1 in /dev/md2 for /dev/sdb3
mdadm: added /dev/sdb3 to /dev/md2 as 1
mdadm: added /dev/sdc3 to /dev/md2 as 2
mdadm: no uptodate device for slot 3 of /dev/md2
mdadm: added /dev/sda3 to /dev/md2 as 0
mdadm: /dev/md2 has been started with 3 drives (out of 4).

Leider zeigt der immer noch "State : clean, degraded" an

cube>  mdadm --detail /dev/md2
/dev/md2:
        Version : 00.90
  Creation Time : Fri Nov 23 10:13:34 2007
     Raid Level : raid5
     Array Size : 1461199872 (1393.51 GiB 1496.27 GB)
  Used Dev Size : 487066624 (464.50 GiB 498.76 GB)
   Raid Devices : 4
  Total Devices : 3
Preferred Minor : 2
    Persistence : Superblock is persistent

    Update Time : Fri May 29 14:30:28 2009
          State : clean, degraded
 Active Devices : 3
Working Devices : 3
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 64K

           UUID : bc166613:b3a27bd3:5e1731df:037949f2
         Events : 0.504130

    Number   Major   Minor   RaidDevice State
       0       8        3        0      active sync   /dev/sda3
       1       8       19        1      active sync   /dev/hdb3
       2       8       35        2      active sync   /dev/hdc3
       3       0        0        3      removed

Man beachte: [UEU_]

cube> cat proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid6] [raid5] [raid4]
md2 : active raid5 sda3[0] sdb3[1](E) sdc3[2]
      1461199872 blocks level 5, 64k chunk, algorithm 2 [4/3] [UEU_]

md1 : active raid1 sda2[0] sdb2[1] sdc2[2] sdd2[3]
      393472 blocks [4/4] [UUUU]

md0 : active raid1 sda1[0] sdb1[1] sdc1[2] sdd1[3]
      787072 blocks [4/4] [UUUU]

cube> raidtool status 2
/dev/md2 is running, status: CRASHED, rebuilding: None
Device level: RAID 5
Device size: 1426953 MB (1496268668928 bytes)
Disk:
         [/dev/sdc3: Normal]
         [/dev/sdb3: Failed(Which ma]
         [/dev/sda3: Normal]

mdadm --no-degraded?
Was denkt ihr?

 

[saeckereier]

Warum erst sda-d und im Snippet nachher sdx und hdx denke ich..

       --no-degraded
              This  is the reverse of --run in that it inhibits the startup of array unless all expected drives are present.  This is only needed with --scan, and can be used if the physical connections
              to devices are not as reliable as you would like.

Was soll das bringen??
.
.
.
EDIT (autom. Beitragszusammenführung) :
.
Wenn du mutig bist, lässt du ihn das Array neu zusammensetzen und zwingst ihn dazu, es als sauber anzunehmen, viel mehr bleibt dir eh nicht übrig, danach ist dann ein Filesystemcheck zwingend dran. Aber mal als Frage: Wie kommst du dadrauf Hotswapping zu machen, wenn du anscheinend eh den Rechner aufmachen musst. Ohne Komponenten, die das austauschen im Betrieb sicher machen, wäre mir das zu heiß gewesen. Nicht ganz zu Unrecht wie man sieht..

 

[lolomat]

Wenn du mutig bist, lässt du ihn das Array neu zusammensetzen und zwingst ihn dazu, es als sauber anzunehmen, viel mehr bleibt dir eh nicht übrig, danach ist dann ein Filesystemcheck zwingend dran.

Genau das hab ich jetzt getan und mit viel Glück sind keine Daten verloren gegangen.