mdadm-RAID: grow misslungen

Probleme mit Samba, NFS, FTP und Co.
Antworten
stephanhh
Beiträge: 7
Registriert: 24.02.2013 11:03:29

mdadm-RAID: grow misslungen

Beitrag von stephanhh » 17.05.2020 19:52:42

Moin zusammen!

Ich hab da ein Problem und hoffe, dass mir hier jemand ein paar Tips geben kann. Ich hab ja nicht soooo viel Ahnung von Linux, aber habe damals auf Anraten eines Kollegen einen Debian-Server aufgebaut, der ohne grafische Oberfläche startet und nur als Datengrab dient, das per Samba-Freigabe im Netzwerk verfügbar ist. Ist ein AMD64 mit 3GB RAM. Es läuft da drauf: Linux 4.9.0-4-amd64 x86_64. Meistens ist er ausgeschaltet, deshalb ist der auch nicht aktuell, ich weiß. Never change a running system.

Letzter Stand vor ein paar Tagen: 6 Festplatten a 3TB im RAID 5-Betrieb: /dev/md2. Alles bestens:

Code: Alles auswählen

/dev/md2:
        Version : 1.2
  Creation Time : Fri Feb 22 21:40:59 2013
     Raid Level : raid5
     Array Size : 14651317760 (13972.59 GiB 15002.95 GB)
  Used Dev Size : 2930263552 (2794.52 GiB 3000.59 GB)
   Raid Devices : 6
  Total Devices : 6
    Persistence : Superblock is persistent

    Update Time : Sat May 16 14:03:14 2020
          State : clean 
 Active Devices : 6
Working Devices : 6
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 512K

           Name : FileServer:2  (local to host FileServer)
           UUID : 9797f4d1:a0f30786:3e621eb7:a8c5ece7
         Events : 68008

    Number   Major   Minor   RaidDevice State
       0       8       49        0      active sync   /dev/sdd1
       1       8       81        1      active sync   /dev/sdf1
       3       8       97        2      active sync   /dev/sdg1
       4       8      129        3      active sync   /dev/sdi1
       5       8       33        4      active sync   /dev/sdc1
       6       8      113        5      active sync   /dev/sdh1
Aber ich brauchte Platz. Also: 3 weitere Platten a 3TB eingebaut. Die drei neuen Festplatten neu partitioniert, bzw. die Partitionierung mit sgdisk von einer anderen kopiert und die ID neu gesetzt. Sind alle vom selben Typ, insofern geht das. Das sah dann so aus:

Code: Alles auswählen

FileServer:~# parted print
Model: ATA WDC WD30EFRX-68A (scsi)
Disk /dev/sda: 3001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start   End     Size    File system  Name     Flags
 1      1049kB  3001GB  3001GB  ext4         raid5_7


Model: ATA WDC WD30EFRX-68A (scsi)
Disk /dev/sdb: 3001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start   End     Size    File system  Name     Flags
 1      1049kB  3001GB  3001GB  ext4         raid5_8


Model: ATA WDC WD30EFRX-68E (scsi)
Disk /dev/sdc: 3001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start   End     Size    File system  Name     Flags
 1      1049kB  3001GB  3001GB               raid5_5


Model: ATA WDC WD30EFRX-68A (scsi)
Disk /dev/sdd: 3001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start   End     Size    File system  Name     Flags
 1      1049kB  3001GB  3001GB               raid5_1


Model: ATA WDC WD30EFRX-68A (scsi)
Disk /dev/sde: 3001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start   End     Size    File system  Name     Flags
 1      1049kB  3001GB  3001GB  ext4         raid5_9


Model: ATA WDC WD30EFRX-68A (scsi)
Disk /dev/sdf: 3001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start   End     Size    File system  Name     Flags
 1      1049kB  3001GB  3001GB               raid5_2


Model: Linux device-mapper (linear) (dm)
Disk /dev/mapper/FileServer-root: 7789MB
Sector size (logical/physical): 512B/512B
Partition Table: loop

Number  Start  End     Size    File system  Flags
 1      0,00B  7789MB  7789MB  ext3


Model: Linux device-mapper (linear) (dm)
Disk /dev/mapper/FileServer-swap_1: 403MB
Sector size (logical/physical): 512B/512B
Partition Table: loop

Number  Start  End    Size   File system     Flags
 1      0,00B  403MB  403MB  linux-swap(v1)


Model: Linux Software RAID Array (md)
Disk /dev/md2: 15,0TB
Sector size (logical/physical): 512B/4096B
Partition Table: loop

Number  Start  End     Size    File system  Flags
 1      0,00B  15,0TB  15,0TB  ext3


Model: ATA WDC WD30EFRX-68A (scsi)
Disk /dev/sdi: 3001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start   End     Size    File system  Name     Flags
 1      1049kB  3001GB  3001GB               raid5_4


Model: ATA WDC WD30EFRX-68A (scsi)
Disk /dev/sdg: 3001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start   End     Size    File system  Name     Flags
 1      1049kB  3001GB  3001GB               raid5_3


Model: ATA WDC AC28400R (scsi)
Disk /dev/sdj: 8455MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End     Size    Type      File system  Flags
 1      32,3kB  255MB   255MB   primary   ext3         boot
 2      255MB   8447MB  8192MB  extended
 5      255MB   8447MB  8192MB  logical                lvm


Model: ATA WDC WD30EFRX-68E (scsi)
Disk /dev/sdh: 3001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start   End     Size    File system  Name     Flags
 1      1049kB  3001GB  3001GB               raid5_6

Nach einem Neustart dann also das Arry vergrößert, von 6 auf 9 Platten:

Code: Alles auswählen

FileServer:~# mdadm --grow --raid-devices=9 /dev/md2
Das lief auch ohne Probleme:

Code: Alles auswählen

FileServer:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4] [linear] [multipath] [raid0] [raid1] [raid10] 
md2 : active raid5 sde1[9] sdb1[8] sda1[7] sdd1[0] sdc1[5] sdf1[1] sdg1[3] sdi1[4] sdh1[6]
      14651317760 blocks super 1.2 level 5, 512k chunk, algorithm 2 [9/9] [UUUUUUUUU]
      [>....................]  reshape =  0.1% (3254452/2930263552) finish=1611.4min speed=30272K/sec
Schneller geht es leider nicht, wahrscheinlich weil der Prozessor dann doch etwas alt ist, das RAM nicht ausreicht und und und. Aber egal.

Heute hab ich nachgeschaut, und da sah das dann anders aus. Es waren keine 50% oder so geschafft. Nein, es sieht jetzt so aus:

Code: Alles auswählen

FileServer:/etc# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4] [linear] [multipath] [raid0] [raid1] [raid10]
md2 : active raid5 sdb1[8] sdd1[0] sdc1[5] sdf1[1] sdg1[3] sdi1[4] sdh1[6]
      14651317760 blocks super 1.2 level 5, 512k chunk, algorithm 2 [9/8] [UUUUUU_U_]

unused devices: <none>

Code: Alles auswählen

FileServer:/etc# mdadm --detail /dev/md2
mdadm: Unknown keyword mdadm.conf
/dev/md2:
        Version : 1.2
  Creation Time : Fri Feb 22 21:40:59 2013
     Raid Level : raid5
     Array Size : 14651317760 (13972.59 GiB 15002.95 GB)
  Used Dev Size : 2930263552 (2794.52 GiB 3000.59 GB)
   Raid Devices : 9
  Total Devices : 7
    Persistence : Superblock is persistent

    Update Time : Sun May 17 19:03:16 2020
          State : clean, FAILED
 Active Devices : 7
Working Devices : 7
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 512K

  Delta Devices : 3, (6->9)

           Name : FileServer:2  (local to host FileServer)
           UUID : 9797f4d1:a0f30786:3e621eb7:a8c5ece7
         Events : 73792

    Number   Major   Minor   RaidDevice State
       0       8       49        0      active sync   /dev/sdd1
       1       8       81        1      active sync   /dev/sdf1
       3       8       97        2      active sync   /dev/sdg1
       4       8      129        3      active sync   /dev/sdi1
       5       8       33        4      active sync   /dev/sdc1
       6       8      113        5      active sync   /dev/sdh1
       -       0        0        6      removed
       8       8       17        7      active sync   /dev/sdb1
       -       0        0        8      removed
Da fehlen also zwei der neuen Platten, /dev/sda und /dev/sde. Warum auch immer! Vorher waren in dem Server 12 Platten, jetzt nur 9. Die Controller funktionierten einwandfrei und bewegt habe ich den Server auch nicht (also unwahrscheinlich, dass sich gleich zwei Kabel gelöst haben). Trotzdem sind die Platten nicht mehr verfügbar.

Ein umount habe ich vor dem grow vergessen. Ob das nötig gewesen wäre, weiß ich nicht. Die Verzeichnisstruktur ist noch da, aber wenn ich - egal ob von Windows oder von Debian aus - auf die Daten zugreifen will, dann bekomme ich EA-Fehler.

Ich bräuchte mal ein paar Ideen, glaube ich. Wie ich inzwischen herausgefunden habe, habe ich den grundsätzlichen Fehler gemacht, dass ext3 wohl gar nicht für so ein großes Dateisystem gemacht ist. Oder doch? Man findet auf den ersten Blick immer nur den Hinweis "bei 32 Bit sind es 16TB", aber nie, ob es bei 64 Bit mehr ist.
Im Moment wage ich es nicht, das Teil neu zu starten, eben weil zumindest die Verzeichnisse noch lesbar sind. Andererseits muss ich ja irgendwie die beiden Festplatten wieder bekommen, und das wird wohl nur durch einen Neustart gehen.

Wie würdet ihr jetzt vorgehen um die Daten zu retten oder gar das ganze System wieder lauffähig zu bekommen? Ach ja: bevor jetzt jemand fragt, was denn das z.B. syslog meint: es meint nichts. Ich habe keine Ahnung, warum, aber der letzte Eintrag ist von November 2017. Irgendwas ist auch da im argen. Ich müßte das System komplett neu aufsetzen, fürchte ich, also mit neuem Debian, neuem ext4-RAID 5, und womöglich sogar neuer Hardware.


Aber kurzfristig bräuchte ich mal eine Idee, was ich machen soll. Also nach dem nächsten Hochfahren mit hoffentlich allen Platten. Läuft das 'grow' automatisch wieder an oder was muss ich tun, damit das wieder läuft? Ein 'forced' zusammenstellen des alten RAID 5-Systems wird ja nicht funktionieren, weil das 'grow' ja schon zu 30-50% durch war.
Was muss ich sonst beachten?
Was kann ich jetzt noch vor dem Ausschalten tun?

Antworten