Die Lösung fand sich in folgender Zeile in der mdadm-Konfigurationsdatei

/etc/mdadm/mdadm.conf

ARRAY /dev/md0 metadata=1.2 spares=1 name=nas:RAID5 UUID=a6bbae11:8c383011:676a08ca:60cfd488

Dort wird explizit eine Festplatte als Spare-Festplatte reserviert, so dass ich die Zeile wie folgt geändert habe:

ARRAY /dev/md0 metadata=1.2 spares=0 name=nas:RAID5 UUID=a6bbae11:8c383011:676a08ca:60cfd488

Damit aus der Spare-Festplatte jetzt eine aktive Festplatte im RAID Array wird, habe ich das RAID Array unter Angabe der Anzahl der RAID-Festplatten vergrößert:

mdadm --grow /dev/md0 --raid-devices=6

Seitdem läuft nun das Reshaping, also das erneute Anordnen oder Reorganisieren des RAID Arrays, wie man mit 

cat /proc/mdstat

Personalities : [raid6] [raid5] [raid4] 
md0 : active raid5 sdf[5] sdc[0] sde[4] sdd[3] sdb[2] sda[1]
      15627548672 blocks super 1.2 level 5, 512k chunk, algorithm 2 [6/6] [UUUUUU]
      [================>....]  reshape = 84.0% (3282224128/3906887168) finish=155.9min speed=66761K/sec
      
unused devices: <none>

Nun sieht man deutlich, dass keine Spare-Festplatte mehr vorhanden ist und alle Festplatten als aktiv genutzte Festplatte zum RAID Array gehören:

Warum dieses Verhalten nicht schon beim Hinzufügen der vierten oder fünften Festplatte aufgetreten ist weiß ich nicht, aber die Lösung war zum Glück einfach zu finden.

Ich habe keine Plugins installiert und ansonsten eine recht schlichte Konfiguration, weshalb ein Update wahrscheinlich ohne großes Risiko durchgeführt werden kann. Wem das zu riskant ist, der sollte eine Neuinstallation und eine anschließende Migration der Daten vornehmen. Dem Wiki ist jedenfalls zu entnehmen, dass ein Update als root Benutzer mit dem Befehl 

omv-release-upgrade

Processing triggers for initramfs-tools (0.120+deb8u3) ...
update-initramfs: Generating /boot/initrd.img-3.16.0-4-amd64
Errors were encountered while processing:
 postfix
 bsd-mailx
 openmediavault
Creating index of upgradeable packages ...
Creating index of openmediavault plugins ...
E: Sub-process /usr/bin/dpkg returned an error code (1)

Nach einem Neustart wurde beim Aufruf des openmediavault Webzugangs nur eine weiße Seite angezeigt. Um das Problem zu beheben, habe ich folgende Schritte durchgeführt, wobei der Tipp größtenteils aus dem openmediavault Forum stammt:

omv-initsystem 
omv-update 
omv-mkconf nginx
omv-mkconf php5fpm
service php5-fpm restart
service nginx restart

Anschließend hat openmediavault wieder korrekt funktioniert, ich konnte mich einloggen und bei Durchsicht aller Einstellungen und Testen der NFS Verbindung waren keine Fehler festzustellen.

Somit ist jetzt auch das nächste System wieder auf aktuellem Stand.

Das System läuft nicht permanent, ich nutze ein kleines Script, um es bei Nichtgebrauch herunterzufahren. Ich muss zugeben, dass ich kein RAID-Experte bin. Ich weiß wie bzw. wo Daten und Paritäten gespeichert werden, wie ich es erweitere und bei Bedarf eine defekte Festplatte tauschen kann. Mir ist auch bekannt, dass die langsame CPU den Flaschenhals bildet, da das Berechnen der Paritäten recht aufwendig ist. Aber wenn ich nach dem Hochfahren eine größere Datenmenge auf das RAID5 schreibe, hängt das System für mehrere Minuten beinahe vollständig. Nach ein paar Minuten kann ich problemlos mit recht hoeher Geschwindigeit Daten schreiben.

Folgendes Beispiel veranschaulicht das Verhalten:

# 10 GB Testdaten schreiben:
dd if=/dev/zero of=test.img bs=1M count=10000
# und gleichzeit iotop aufrufen:
iotop -b -n 1 -o
Total DISK READ:       2.88 M/s | Total DISK WRITE:       0.00 B/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
 5472 be/4 root        2.58 M/s    0.00 B/s  0.00 % 99.99 % [flush-9:0]

Die Load geht bis etwa 10 hoch, top zeigt einen hohe iowait:

%Cpu(s):  0,0 us,  1,2 sy,  0,0 ni, 50,8 id, 47,5 wa,  0,0 hi,  0,5 si,  0,0 st

Natürlich verursacht das Schreiben eine hohe IO-Aktivität und auch das flush-Prinzip ist mir bekannt, denn auf Linux Systemen werden Daten häufig asynchron erst in dem RAM und dann auf die Festplatten geschrieben, um eine möglichst hohe Performance zu gewährleisten. Wirklich stutzig macht mich hier aber die Tatsache, dass flush Daten liest. Das Resultat ist eine scheinbar schlechte Schreibperformance:

10485760000 Bytes (10 GB) kopiert, 525,175 s, 20,0 MB/s

Der zweite und jede weitere Schreibvorgang hingegen läuft deutlich schneller:

10485760000 Bytes (10 GB) kopiert, 62,9669 s, 167 MB/s

167 MB/s sind für diese schwache CPU in meinem Augen völlig zufriedenstellend. Die Lesegeschwindigkeit ist ebenfalls in Ordnung:

10485760000 Bytes (10 GB) kopiert, 37,6012 s, 279 MB/s

Ein Graph der Arbeitsspeicherauslastung (auch manuell mit

free -m

Der hellblaue Bereich ist der Cache, der nach dem Booten (etwa gegen 18:30 Uhr) kaum verwendet wird. Ab etwa 18:47 Uhr wächst der hellblaue Bereich, bis er ein paar Minuten später (18:55 Uhr) sprunghaft ansteigt und um 18:56 Uhr sein Maximum erreicht hat. Innerhalb dieses Zeitraums wird ebenfalls der Buffer beansprucht, der dann wieder kleiner wird, da Daten dann auf die Festplatte geschrieben werden können. Danach läuft alles wieder normal und es können ohne spürbare Performance-Engpässe Daten geschrieben werden.

Ich frage mich, was genau der flush-Prozess während des Schreibens liest und warum das Schreiben dadurch so enorm blockiert wird. Wahrscheinlich ist dies ein recht normales Verhalten, welches aber kaum auffällt, da die meisten NAS Systeme über mehr Leistung verfügen und nur selten neu gestartet werden. Aber vielleicht liegt tatsächlich ein Problem vor und ich sehe es nur nicht.

Welche Art von Daten benötigt Linux im RAM, bevor es performant schreiben kann und wie lässt sich dieser Prozess optimieren? An diesem Punkt stelle ich leider wieder einmal fest, dass mein Wissen nicht ausreicht und ich noch einiges vor mir habe. Auch das Verändern der stripe_cache_size (aktuell 8192, auch kleinere Werte bis 256 habe ich probiert) bringt bei diesem Problem keine Veränderung. Früher oder später wird sich aber eine Lösung oder zumindest eine Erklärung finden lassen. Was mich aber wundert: Hat sonst noch nie jemand dieses Verhalten in dieser Größenordnung festgestellt?