ubuntuusers.de

Hallo liebe Community!

Ich habe ein Softwareraid mit mdadm erstellt und nun ca 1 Jahr laufen gehabt.(Ich glaube nie neugestartet) Es handelt sich um ein Raid10 und die Platten sind identisch (WD RED 3TB). Nach einem Kernelupdate heute morgen kann ich mein Raid nicht mehr starten. Das Raid war zum reboot intakt und nahezu Täglich wurden Daten geschrieben. Smartdaten sind bei allen Disks IO.

Hier die wichtigen Ausgaben.

Versuch des Zusammenbaus:

mdadm --assemble --verbose /dev/md0 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sdf1 /dev/sdg1
mdadm: looking for devices for /dev/md0
mdadm: /dev/sda1 is identified as a member of /dev/md0, slot 0.
mdadm: /dev/sdb1 is identified as a member of /dev/md0, slot 1.
mdadm: /dev/sdc1 is identified as a member of /dev/md0, slot 5.
mdadm: /dev/sdd1 is identified as a member of /dev/md0, slot 2.
mdadm: /dev/sdf1 is identified as a member of /dev/md0, slot 4.
mdadm: /dev/sdg1 is identified as a member of /dev/md0, slot 3.
mdadm: added /dev/sdb1 to /dev/md0 as 1
mdadm: added /dev/sdd1 to /dev/md0 as 2
mdadm: added /dev/sdg1 to /dev/md0 as 3
mdadm: failed to add /dev/sdf1 to /dev/md0: Invalid argument
mdadm: failed to add /dev/sdc1 to /dev/md0: Invalid argument
mdadm: added /dev/sda1 to /dev/md0 as 0
mdadm: /dev/md0 assembled from 4 drives - need all 6 to start it (use --run to insist).

dmesg:

[  560.211963] md: md0 stopped.
[  560.213820] md: bind<sdb1>
[  560.214082] md: bind<sdd1>
[  560.214290] md: bind<sdg1>
[  560.214572] md: sdf1 does not have a valid v1.2 superblock, not importing!
[  560.214593] md: md_import_device returned -22
[  560.214835] md: sdc1 does not have a valid v1.2 superblock, not importing!
[  560.214851] md: md_import_device returned -22
[  560.215084] md: bind<sda1>
[  560.227380] md/raid10:md0: not enough operational mirrors.
[  560.227452] md: pers->run() failed ...
[  560.227497] md: md0 stopped.
[  560.227512] md: unbind<sda1>
[  560.249115] md: export_rdev(sda1)
[  560.249145] md: unbind<sdg1>
[  560.269123] md: export_rdev(sdg1)
[  560.269169] md: unbind<sdd1>
[  560.285096] md: export_rdev(sdd1)
[  560.285137] md: unbind<sdb1>
[  560.301085] md: export_rdev(sdb1)

mdadm -E:

/dev/sda1:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : e9044728:aecf6504:59e687b8:2eaa4005
           Name : Skynet:1  (local to host Skynet)
  Creation Time : Mon Sep 19 22:45:01 2016
     Raid Level : raid10
   Raid Devices : 6

 Avail Dev Size : 5860261775 (2794.39 GiB 3000.45 GB)
     Array Size : 8790389760 (8383.17 GiB 9001.36 GB)
  Used Dev Size : 5860259840 (2794.39 GiB 3000.45 GB)
    Data Offset : 261120 sectors
   Super Offset : 8 sectors
   Unused Space : before=261032 sectors, after=1935 sectors
          State : clean
    Device UUID : b548b820:ba1aed40:d223f0fc:961d3e50

Internal Bitmap : 8 sectors from superblock
    Update Time : Wed Sep 28 07:13:58 2016
  Bad Block Log : 512 entries available at offset 72 sectors
       Checksum : 6e531ed - correct
         Events : 15235

         Layout : near=2
     Chunk Size : 512K

   Device Role : Active device 0
   Array State : AAAAAA ('A' == active, '.' == missing, 'R' == replacing)
=========================================================================================

/dev/sdb1:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : e9044728:aecf6504:59e687b8:2eaa4005
           Name : Skynet:1  (local to host Skynet)
  Creation Time : Mon Sep 19 22:45:01 2016
     Raid Level : raid10
   Raid Devices : 6

 Avail Dev Size : 5860261775 (2794.39 GiB 3000.45 GB)
     Array Size : 8790389760 (8383.17 GiB 9001.36 GB)
  Used Dev Size : 5860259840 (2794.39 GiB 3000.45 GB)
    Data Offset : 261120 sectors
   Super Offset : 8 sectors
   Unused Space : before=261032 sectors, after=1935 sectors
          State : clean
    Device UUID : 007ea95f:3ea345be:dcfc5226:970ec11d

Internal Bitmap : 8 sectors from superblock
    Update Time : Wed Sep 28 07:13:58 2016
  Bad Block Log : 512 entries available at offset 72 sectors
       Checksum : ba14b9c7 - correct
         Events : 15235

         Layout : near=2
     Chunk Size : 512K

   Device Role : Active device 1
   Array State : AAAAAA ('A' == active, '.' == missing, 'R' == replacing)
==========================================================================================

/dev/sdc1:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : e9044728:aecf6504:59e687b8:2eaa4005
           Name : Skynet:1  (local to host Skynet)
  Creation Time : Mon Sep 19 22:45:01 2016
     Raid Level : raid10
   Raid Devices : 6

 Avail Dev Size : 5860269056 (2794.39 GiB 3000.46 GB)
     Array Size : 8790389760 (8383.17 GiB 9001.36 GB)
  Used Dev Size : 5860259840 (2794.39 GiB 3000.45 GB)
    Data Offset : 261120 sectors
   Super Offset : 8 sectors
   Unused Space : before=261032 sectors, after=1935 sectors
          State : clean
    Device UUID : af0b5dfb:a1bbaddc:2840c445:70adf799

Internal Bitmap : 8 sectors from superblock
    Update Time : Wed Sep 28 07:13:58 2016
  Bad Block Log : 512 entries available at offset 72 sectors
       Checksum : fd85e74 - correct
         Events : 15235

         Layout : near=2
     Chunk Size : 512K

   Device Role : Active device 5
   Array State : AAAAAA ('A' == active, '.' == missing, 'R' == replacing)
===========================================================================================

/dev/sdd1:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : e9044728:aecf6504:59e687b8:2eaa4005
           Name : Skynet:1  (local to host Skynet)
  Creation Time : Mon Sep 19 22:45:01 2016
     Raid Level : raid10
   Raid Devices : 6

 Avail Dev Size : 5860261775 (2794.39 GiB 3000.45 GB)
     Array Size : 8790389760 (8383.17 GiB 9001.36 GB)
  Used Dev Size : 5860259840 (2794.39 GiB 3000.45 GB)
    Data Offset : 261120 sectors
   Super Offset : 8 sectors
   Unused Space : before=261032 sectors, after=1935 sectors
          State : clean
    Device UUID : ee42b87a:a9347880:c94354a5:28632c60

Internal Bitmap : 8 sectors from superblock
    Update Time : Wed Sep 28 07:13:58 2016
  Bad Block Log : 512 entries available at offset 72 sectors
       Checksum : 58c2aba0 - correct
         Events : 15235

         Layout : near=2
     Chunk Size : 512K

   Device Role : Active device 2
   Array State : AAAAAA ('A' == active, '.' == missing, 'R' == replacing)
=============================================================================================

/dev/sdf1:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : e9044728:aecf6504:59e687b8:2eaa4005
           Name : Skynet:1  (local to host Skynet)
  Creation Time : Mon Sep 19 22:45:01 2016
     Raid Level : raid10
   Raid Devices : 6

 Avail Dev Size : 5860269056 (2794.39 GiB 3000.46 GB)
     Array Size : 8790389760 (8383.17 GiB 9001.36 GB)
  Used Dev Size : 5860259840 (2794.39 GiB 3000.45 GB)
    Data Offset : 261120 sectors
   Super Offset : 8 sectors
   Unused Space : before=261032 sectors, after=1935 sectors
          State : clean
    Device UUID : 8c6eb1bb:d0cba15c:48a27e60:3e0a2ee5

Internal Bitmap : 8 sectors from superblock
    Update Time : Wed Sep 28 07:13:58 2016
  Bad Block Log : 512 entries available at offset 72 sectors
       Checksum : b611906e - correct
         Events : 15235

         Layout : near=2
     Chunk Size : 512K

   Device Role : Active device 4
   Array State : AAAAAA ('A' == active, '.' == missing, 'R' == replacing)
==============================================================================================

/dev/sdg1:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : e9044728:aecf6504:59e687b8:2eaa4005
           Name : Skynet:1  (local to host Skynet)
  Creation Time : Mon Sep 19 22:45:01 2016
     Raid Level : raid10
   Raid Devices : 6

 Avail Dev Size : 5860261775 (2794.39 GiB 3000.45 GB)
     Array Size : 8790389760 (8383.17 GiB 9001.36 GB)
  Used Dev Size : 5860259840 (2794.39 GiB 3000.45 GB)
    Data Offset : 261120 sectors
   Super Offset : 8 sectors
   Unused Space : before=261032 sectors, after=1935 sectors
          State : clean
    Device UUID : 1bf08072:2cefe14c:030bc1d0:9b824650

Internal Bitmap : 8 sectors from superblock
    Update Time : Wed Sep 28 07:13:58 2016
  Bad Block Log : 512 entries available at offset 72 sectors
       Checksum : 387bf9fe - correct
         Events : 15235

         Layout : near=2
     Chunk Size : 512K

   Device Role : Active device 3
   Array State : AAAAAA ('A' == active, '.' == missing, 'R' == replacing)

Bevor ich jetzt mit tollen Tips wie "Überschreib mal den Superblock von Disk XY" loslege wollte ich mal hier fragen ob jemand eine Lösung bzw. das Problem kennt. Ich hatte mich für ein Raid10 entschieden um Datenverlust zu vermeiden. Aktuell stellt sich die Situation wohl so dar als wären meine Daten ohne Raid besser aufgehomen gewesen 😀 Tips verry Welcome

Danke und Gruß

derdigge

derdigge schrieb:

Ich habe ein Softwareraid mit mdadm erstellt und nun ca 1 Jahr laufen gehabt.(Ich glaube nie neugestartet) Es handelt sich um ein Raid10 und die Platten sind identisch (WD RED 3TB).

Nach einem Kernelupdate heute morgen kann ich mein Raid nicht mehr starten.

Das war Dein erstes Kernelupdate seit einem Jahr? Hast das System auch insgesamt vollstängig aktualisiert? Wie kannst Du ein Softwareraid ohne Neustart mit 16.04 seit 1 Jahr laufen haben?

Irgendwie ist das inkonsistent oder es fehlen Infos.

Kannst du auch mal cat /etc/{mdadm/,}mdadm.conf; cat /proc/mdstat; blockdev --getsize64 /dev/sd??1; parted /dev/sd?? unit s print free; und mdadm --examine-badblocks /dev/sd???1 zeigen?

Daß auf der einen Seite der Superblock angeblich invalide ist und auf der anderen Seite --examine ihn anzeigt inkl. korrekter Checksumme ist etwas ungewöhnlich.

Passiert dies auch von einem Rettungssystem aus (SystemRescueCD o.ä.)?

Danke für eure Zeit und die schnellen Antworten!

Ja es läuft seit ca einem Jahr(Vielleicht auch nur 9 Monate). Hier fehlt etwas weiterführende Erklärung, unvollständig von mir beschrieben, sorry. Ausgangspunkt war mal ein raid0 (2 Platten) neben einem RAID10 (4 Platten) für mehr Speicher sowie bessere Datensicherheit parallel im selben System. Dann habe ich das raid0 aufgelöst, habe die beiden Platten in das raid10 "gegrowd" und mittels resize2fs das Dateisystem erweitert. Dieses gewachsene raid10 ist nun seit ca 2 Wochen so gemountet und in Benutzung gewesen - no issues. Die Systemuptime betrug bis heute morgen etwas um die 280 Tage.

mdadm.conf / mdstat

root@Skynet:~# cat /etc/mdadm/mdadm.conf
# mdadm.conf
#
# Please refer to mdadm.conf(5) for information about this file.
#

# by default (built-in), scan all partitions (/proc/partitions) and all
# containers for MD superblocks. alternatively, specify devices to scan, using
# wildcards if desired.
#DEVICE partitions containers

# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes

# automatically tag new arrays as belonging to the local system
HOMEHOST <system>

# instruct the monitoring daemon where to send mail alerts
MAILADDR root

# definitions of existing MD arrays
ARRAY /dev/md/0  metadata=1.2 UUID=e9044728:aecf6504:59e687b8:2eaa4005 name=Skynet:1

# This file was auto-generated on Wed, 28 Sep 2016 08:47:24 +0200
# by mkconf $Id$


cat /proc/mdstat  Nix los weil nicht gestartet. nach dem boot steht md0 auf inactive
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
unused devices: <none>

blockdev Das passt wie arsch auf Eimer, ist extra so gewählt. Am Ende habe ich auch jeweils ein paar Sektoren "abgeschnitten" falls ich mal ne Platte ersetzen muss.

root@Skynet:~# for d in $(ls /dev/sd*1 | grep -v sde); do printf "$d : " ; blockdev --getsize64 $d ; done
/dev/sda1 : 3000587722240
/dev/sdb1 : 3000587722240
/dev/sdc1 : 3000587722240
/dev/sdd1 : 3000587722240
/dev/sdf1 : 3000587722240
/dev/sdg1 : 3000587722240

parted data:

root@Skynet:~# for part in $(ls /dev/sd* | grep -iEv 'sde|1');do parted $part unit s print free;done
Modell: ATA WDC WD30EFRX-68E (scsi)
Festplatte  /dev/sda:  5860533168s
Sektorgröße (logisch/physisch): 512B/4096B
Partitionstabelle: gpt
Disk-Flags:

Nummer  Anfang       Ende         Größe        Dateisystem   Name              Flags
        34s          2047s        2014s        Freier Platz
 1      2048s        5860524942s  5860522895s  ntfs          Linux filesystem
        5860524943s  5860533134s  8192s        Freier Platz

Modell: ATA WDC WD30EFRX-68E (scsi)
Festplatte  /dev/sdb:  5860533168s
Sektorgröße (logisch/physisch): 512B/4096B
Partitionstabelle: gpt
Disk-Flags:

Nummer  Anfang       Ende         Größe        Dateisystem   Name              Flags
        34s          2047s        2014s        Freier Platz
 1      2048s        5860524942s  5860522895s  ntfs          Linux filesystem
        5860524943s  5860533134s  8192s        Freier Platz

Modell: ATA WDC WD30EFRX-68E (scsi)
Festplatte  /dev/sdc:  5860533168s
Sektorgröße (logisch/physisch): 512B/4096B
Partitionstabelle: gpt
Disk-Flags:

Nummer  Anfang       Ende         Größe        Dateisystem   Name              Flags
        34s          2047s        2014s        Freier Platz
 1      2048s        5860524942s  5860522895s                Linux filesystem
        5860524943s  5860533134s  8192s        Freier Platz

Modell: ATA WDC WD30EFRX-68E (scsi)
Festplatte  /dev/sdd:  5860533168s
Sektorgröße (logisch/physisch): 512B/4096B
Partitionstabelle: gpt
Disk-Flags:

Nummer  Anfang       Ende         Größe        Dateisystem   Name              Flags
        34s          2047s        2014s        Freier Platz
 1      2048s        5860524942s  5860522895s  ntfs          Linux filesystem
        5860524943s  5860533134s  8192s        Freier Platz

Modell: ATA WDC WD30EFRX-68E (scsi)
Festplatte  /dev/sdf:  5860533168s
Sektorgröße (logisch/physisch): 512B/4096B
Partitionstabelle: gpt
Disk-Flags:

Nummer  Anfang       Ende         Größe        Dateisystem   Name              Flags
        34s          2047s        2014s        Freier Platz
 1      2048s        5860524942s  5860522895s                Linux filesystem
        5860524943s  5860533134s  8192s        Freier Platz

Modell: ATA WDC WD30EFRX-68E (scsi)
Festplatte  /dev/sdg:  5860533168s
Sektorgröße (logisch/physisch): 512B/4096B
Partitionstabelle: gpt
Disk-Flags:

Nummer  Anfang       Ende         Größe        Dateisystem   Name              Flags
        34s          2047s        2014s        Freier Platz
 1      2048s        5860524942s  5860522895s  ntfs          Linux filesystem
        5860524943s  5860533134s  8192s        Freier Platz

badblocks:

root@Skynet:~# for part in $(ls /dev/sd*1 | grep -iEv 'sde');do mdadm --examine-badblocks $part;done
Bad-blocks list is empty in /dev/sda1
Bad-blocks list is empty in /dev/sdb1
Bad-blocks list is empty in /dev/sdc1
Bad-blocks list is empty in /dev/sdd1
Bad-blocks list is empty in /dev/sdf1
Bad-blocks list is empty in /dev/sdg1

Rescuesystem kann ich erst nächste Woche Prüfen, da ich nicht vor Ort bin. Aber vielleicht geht ja jemandem anhand der oben geführten Erklärung ein Licht auf.

Danke und Grüße

derdigge schrieb:

Rescuesystem kann ich erst nächste Woche Prüfen, da ich nicht vor Ort bin. Aber vielleicht geht ja jemandem anhand der oben geführten Erklärung ein Licht auf.

Sieht von aussen soweit alles okay aus, schätze du hast einen Bug erwischt.

Du schreibst Kernelupdate, läuft es dann vielleicht mit der vorherigen Kernelversion noch?

Wenn du möchtest, kannst du deine MD metadaten (a la dd bs=64k count=1 if=/dev/sd?1 of=sd?1.header o.ä.) in ein tar verpacken und irgendwo hochladen, dann könnte ich hier damit experimentieren.

PS: Ein Problem ist mir aufgefallen. Du schreibst das RAID lief ein Jahr. Die Metadaten sagen jedoch, Creation Time : Mon Sep 19 22:45:01 2016 also lief es nur eine Woche? Zusammenbauen lassen sollte es sich aber unabhängig davon trotzdem... ob dann Daten drauf sind ist eine andere Geschichte.

Ja wird das Datum des grow sein, könnte zumindest hinkommen. Dieses growen von Raid10 ist neu(ohne lvm) und geht erst seit?juni?juli? Die Platten haben eine uptime von ~540 Tagen. Das entspricht einem "gefühlten Jahr" wenn man jensets der 40 ist 😀

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     0x002f   200   200   051    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0027   177   177   021    Pre-fail  Always       -       39
  4 Start_Stop_Count        0x0032   091   091   000    Old_age   Always       -       39
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   100   253   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   082   082   000    Old_age   Always       -       13440
 10 Spin_Retry_Count        0x0032   100   100   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   253   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       39
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       47
193 Load_Cycle_Count        0x0032   156   156   000    Old_age   Always       -       132355
194 Temperature_Celsius     0x0022   113   104   000    Old_age   Always       -       37
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   100   253   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   100   253   000    Old_age   Offline      -       0

Dann mache ich 8 files, jeweils die ersten 64k der partition? Ich weiss nicht wie Groß der Block ist, der die Metadaten beschreibt. Spielt es eine für dich Rolle wenn es eine LuksPartition ist?

derdigge schrieb:

Ja wird das Datum des grow sein, könnte zumindest hinkommen.

Und danach hat es noch funktioniert? Wie genau durchgeführt?

--grow sollte die creation time nicht ändern.

--create geht meist mit Datenverlust einher, man muss das Layout gut kennen und mdadm ändert gerne seine Defaults so daß man alles haarklein angeben muss.

Dann mache ich 8 files, jeweils die ersten 64k der partition? Ich weiss nicht wie Groß der Block ist, der die Metadaten beschreibt. Spielt es eine für dich Rolle wenn es eine LuksPartition ist?

LUKS hast du dann auf dem RAID oben drauf?

Spielt keine Rolle, im Moment interessieren nur die MD metadaten.

PS: Zufällig irgnedwo --examine Ausgaben von vorher irgendwo aufbewahrt / mal in einem anderen Thread gepostet / ...?

frostschutz schrieb:

derdigge schrieb:

Ja wird das Datum des grow sein, könnte zumindest hinkommen.

Und danach hat es noch funktioniert? Wie genau durchgeführt?

Grow wurde folgendermaßen durchgeführt: Die Daten auf dem alten raid0(zwei Festplatten) wurden weitestgehend auf das bereits bestehende raid10(4 Platten) übertragen(rsync). Dann habe ich das raid0 gestoppt, mit gparted gdisk die vorhandenen Partitionen gelöscht und entsprechend der Logik der Platten im raid10(4 Platten) neu partitioniert. Dann habe ich die beiden neuen leeren Partitionen als hotswap hinzugefügt.

Hier kucke ma, .bash_history for the win!!

.bash_history:mdadm -D /dev/md0
.bash_history:mdadm --stop /dev/md0
.bash_history:gdisk /dev/sdc
.bash_history:gdisk /dev/sdf
.bash_history:mdadm --zero-superblock /dev/sdf
.bash_history:mdadm --zero-superblock /dev/sdf1
.bash_history:mdadm --add /dev/md1 /dev/sdc1 /dev/sdf1
.bash_history:mdadm -D /dev/md1
.bash_history:mdadm --grow -n 6 /dev/md1
.bash_history:cryptsetup luksOpen /dev/md1 hdd --key-file=keyfile
.bash_history:cryptsetup resize hdd
.bash_history:e2fsck -f /dev/mapper/hdd
.bash_history:resize2fs /dev/mapper/hdd

Die beiden Disks die später dazugekommen sind, sind die beiden mit dem Fehler. Ich verstehe nur nicht warum das erst so lange funktioniert hat. Hieraus geht erstmal hervor, das ich die sdc nicht den Superblock geleert habe hmmhmh, war wohl spät an dem Tag.

--grow sollte die creation time nicht ändern.

--create geht meist mit Datenverlust einher, man muss das Layout gut kennen und mdadm ändert gerne seine Defaults so daß man alles haarklein angeben muss.

Wie oben zu sehen so war die Kommando Reihenfolge. Ich habe eben nochmal die bash_history durch gegraben. "Da iss nüscht"

Dann mache ich 8 Files, jeweils die ersten 64k der partition? Ich weiß nicht wie Groß der Block ist, der die Metadaten beschreibt. Spielt es eine für dich Rolle wenn es eine LuksPartition ist?

LUKS hast du dann auf dem RAID oben drauf?

Jep, sollte eig keine Rolle spielen. sobald das raid konsistent ist, ist ihm wurscht was da für Daten rumgeistern.

Spielt keine Rolle, im Moment interessieren nur die MD metadaten.

PS: Zufällig irgnedwo --examine Ausgaben von vorher irgendwo aufbewahrt / mal in einem anderen Thread gepostet / ...?

Leider nein...

Vielleicht die Disks nochmal rausnehmen aus dem Verbund? Ich müsste das ja alles wieder schrinken. Das Raid syncen dauert den ganzen Tag ☺. Die Metadaten sind auf jeden Fall erstmal im Anhang als tar.

EDIT

Es ist der Hammer, wie weit die bash_history zurückreicht. Hier mal wie ich das Raid vor vielen Monden erstellt habe ☺

gdisk /dev/sda
gdisk /dev/sdb
gdisk /dev/sdd
gdisk /dev/sdg
mdadm --create /dev/md1 --auto md --level=10 --raid-devices=4 /dev/sda1 /dev/sdb1 /dev/sdd1 /dev/sdg1

Das Anhängen hat im anderen post nicht geklappt.

Also ich hab das jetzt extra nochmal ausprobiert (mit und ohne Ubuntu)... RAID 10 angefangen mit zwei Platten, Grow auf 4, Grow auf 6, Creation Time bleibt gleich. Das ist also sehr mysteriös.

Das Datum wirst beim ersten --create wohl ja nicht auf heute von vor einer Woche gestellt haben...

Dein Problem kann ich schonmal reproduzieren.

# mdadm --assemble /dev/md42 /dev/loop[1-6]
mdadm: failed to add /dev/loop5 to /dev/md42: Invalid argument
mdadm: failed to add /dev/loop3 to /dev/md42: Invalid argument
mdadm: /dev/md42 assembled from 4 drives - need all 6 to start it (use --run to insist).

md: loop5 does not have a valid v1.2 superblock, not importing!
md: md_import_device returned -22
md: loop3 does not have a valid v1.2 superblock, not importing!
md: md_import_device returned -22

Muss ich mir genauer anschauen. Ich melde mich nachher nochmal.

Das einzige was sonst noch auffällt ist daß du da irgendwelche alten NTFS Signaturen drin hast, aber daran sollte es eigentlich nicht liegen (ist auch nicht / nur bei den beiden der Fall).

Die Festplatten hatte ich bei ebay geschossen(alle 6). Die kamen aus einen QNAP NAS, wo jemand größere eingebaut hat. Die hatten keine 500h uptime. Ich wüsste ja nicht wieso man bei qnap ntfs partitionieren sollte.... Wäre aber meine Erklärung. Ich habe, außer auf der Arbeit, seit ~10 Jahren keine Windose mehr.

Ich hab die Ursache gefunden... scheinbar waren die Partitionen zu dem Zeitpunkt wo du hinzugefügt hast, größer. Und md meckert jetzt weil angeblich zu klein.

Bei deinem mdadm --examine ist diese Abweichung im Punkt "Avail Dev Size : " zu sehen.

 Avail Dev Size : 5860261775 (2794.39 GiB 3000.45 GB)
 Avail Dev Size : 5860261775 (2794.39 GiB 3000.45 GB)
 Avail Dev Size : 5860269056 (2794.39 GiB 3000.46 GB)
 Avail Dev Size : 5860261775 (2794.39 GiB 3000.45 GB)
 Avail Dev Size : 5860269056 (2794.39 GiB 3000.46 GB)
 Avail Dev Size : 5860261775 (2794.39 GiB 3000.45 GB)

Obwohl diese gar nicht verwendet wird (Used Dev Size ist identisch) ist md nicht beizubringen dieses Problem zu ignorieren oder Avail Dev Size zu verringern.

Du hast ja hinter deinen Partitionen noch etwas Luft. Vielleicht reicht es diese um die fehlenden 7281 Sektoren zu vergrößern. Ansonsten müssen wir Metadaten editieren...

Krass man, du bist der Hammer !! ☺

Jetzt sehe ich es auch.

root@Skynet:~# for part in $(ls /dev/sd*1 | grep -iEv 'sde');do printf "\n\n$part\n" ; mdadm -E $part| grep -iE 'Avail Dev Size|Used Dev Size' ;done


/dev/sda1
 Avail Dev Size : 5860261775 (2794.39 GiB 3000.45 GB)
  Used Dev Size : 5860259840 (2794.39 GiB 3000.45 GB) diff 1935


/dev/sdb1
 Avail Dev Size : 5860261775 (2794.39 GiB 3000.45 GB)
  Used Dev Size : 5860259840 (2794.39 GiB 3000.45 GB) diff 1935


/dev/sdc1
 Avail Dev Size : 5860269056 (2794.39 GiB 3000.46 GB) << need fix to 5860261775 
  Used Dev Size : 5860259840 (2794.39 GiB 3000.45 GB) diff 9216


/dev/sdd1
 Avail Dev Size : 5860261775 (2794.39 GiB 3000.45 GB)
  Used Dev Size : 5860259840 (2794.39 GiB 3000.45 GB) diff 1935


/dev/sdf1
 Avail Dev Size : 5860269056 (2794.39 GiB 3000.46 GB) << need fix to 5860261775
  Used Dev Size : 5860259840 (2794.39 GiB 3000.45 GB) diff 9216


/dev/sdg1
 Avail Dev Size : 5860261775 (2794.39 GiB 3000.45 GB)
  Used Dev Size : 5860259840 (2794.39 GiB 3000.45 GB) diff 1935

Ich denke eine saubere Lösung wäre es die Metadaten zu editieren. Aktuell sind ja alle Partitionen exakt gleich Groß:

root@Skynet:~# grep -iE 'sd[abcdfg]1' /proc/partitions | awk '{print $3}'
2930261447
2930261447
2930261447
2930261447
2930261447
2930261447

Ich habe so etwas noch nie getan. Da es wohl aufgrund meiner Daten eine Operation am offenen Herzen darstellt, frage ich vorher nochmal nach ☺

Die Größe ist definitiv identisch:

root@Skynet:~# for part in $(ls /dev/sd* | grep -iEv 'sde|1');do parted $part unit s print free | awk '/2048s/ {print $4}';done
5860522895s
5860522895s
5860522895s
5860522895s
5860522895s
5860522895s

Wie man RAID Metadaten editiert. Nachmachen auf eigene Gefahr.

Das Format ist hier beschrieben: https://raid.wiki.kernel.org/index.php/RAID_superblock_formats#The_version-1_superblock_format_on-disk_layout

Der Superblock beginnt bei 4K also bei den dort genannten Offsets immer +4096.

Ich schätze der Wert um den es geht ist: 0x88 - 0x8F 136 - 143 8 data_size # of sectors that can be used for data

$ for f in *.bin
do
    echo ---- "$f" ----
    hexdump -C -s $((4096+136)) -n 8 "$f"
done

Ausgabe:

---- sda1.bin ----
00001088  8f 7f 4c 5d 01 00 00 00                           |..L]....|
00001090
---- sdb1.bin ----
00001088  8f 7f 4c 5d 01 00 00 00                           |..L]....|
00001090
---- sdc1.bin ----
00001088  00 9c 4c 5d 01 00 00 00                           |..L]....|
00001090
---- sdd1.bin ----
00001088  8f 7f 4c 5d 01 00 00 00                           |..L]....|
00001090
---- sdf1.bin ----
00001088  00 9c 4c 5d 01 00 00 00                           |..L]....|
00001090
---- sdg1.bin ----
00001088  8f 7f 4c 5d 01 00 00 00                           |..L]....|
00001090

Dezimal interpretiert (verdammte Bytefolge):

$ echo $((0x015d4c9c00))
5860269056
$ echo $((0x015d4c7f8f))
5860261775

Das sind die von mdadm --examine angezeigten Werte.

Ändern am einfachsten indem man von da klaut wo es passt:

# dd conv=notrunc bs=1 count=8 seek=$((4096+136)) skip=$((4096+136)) if=sda1.bin of=sdc1.bin
# dd conv=notrunc bs=1 count=8 seek=$((4096+136)) skip=$((4096+136)) if=sda1.bin of=sdf1.bin

Soweit wäre das geändert, aber die Metadaten haben auch eine Checksumme die jetzt nicht mehr stimmt.

# mdadm --examine $(losetup --find --show sdc1.bin)
 Avail Dev Size : 5860261775 (2794.39 GiB 3000.45 GB)
       Checksum : fd85e74 - expected fd84203
# mdadm --examine $(losetup --find --show sdf1.bin)
 Avail Dev Size : 5860261775 (2794.39 GiB 3000.45 GB)
       Checksum : b611906e - expected b61173fd

Checksumme ist dieser Wert: 0xD8 - 0xDB 216 - 219 4 sb_csum Checksum of this superblock

$ for f in *.bin
do
    echo ---- "$f" ----
    hexdump -C -s $((4096+216)) -n 4 "$f"
done

Ausgabe:

---- sdc1.bin ----
000010d8  74 5e d8 0f                                       |t^..|
000010dc
---- sdf1.bin ----
000010d8  6e 90 11 b6                                       |n...|
000010dc

Hier wieder das gleiche, die Bytefolge ist zu beachten [weil rückwärts]. Besonders fies bei dem Beispiel: mdadm --examine lässt in der Ausgabe die führende 0 einfach so aus, das erste Byte von sdc1 ist nicht fd sondern 0f... daß die erwartete Checksumme überhaupt angegeben ist, das ist schon ein Wunder, ohne die kämen wir hier nämlich nicht weiter.

Auf die erwartete Checksumme ändern:

# echo -n -e '\x03\x42\xd8\x0f' | dd conv=notrunc bs=1 count=4 seek=$((4096+216)) of=sdc1.bin
# echo -n -e '\xfd\x73\x11\xb6' | dd conv=notrunc bs=1 count=4 seek=$((4096+216)) of=sdf1.bin

Dann sollte das passen.

Am Ende noch Loopdevices aufräumen:

# losetup -D

Wenn du das NTFS Zeugs auch loswerden willst:

# wipefs -n sda1.bin
offset               type
----------------------------------------------------------------
0x1fe                PMBR   [partition table]

0x1000               linux_raid_member   [raid]
                     LABEL: Skynet:1
                     UUID:  e9044728-aecf-6504-59e6-87b82eaa4005
# wipefs --force -o 0x1fe sda1.bin 
sda1.bin: 2 bytes were erased at offset 0x000001fe (PMBR): 55 aa
# wipefs -n sda1.bin
offset               type
----------------------------------------------------------------
0x1000               linux_raid_member   [raid]
                     LABEL: Skynet:1
                     UUID:  e9044728-aecf-6504-59e6-87b82eaa4005

Und wenn du dir 140% sicher bist alles richtig gemacht zu haben dann kannst du das bin Zeug zurück auf die Platten spulen.

Alle Angaben wie immer ohne Gewähr.