Linux.raid

"md" ist ein Kernel Bestandteil von Linux mit dem man per Software ein RAID-System aufbauen kann. md stellt dem Linux System eine virtuelle Partition zur Verfügung (in der Regel "/dev/md0") die es "so" gar nicht real auf der/den Festplatte(n) gibt. Je nach RAID Level werden Schreib- Lesezugriff auf /dev/md0 durch die md-Software auf die realen Partitionen weitergegeben. RAID kann für mehr Datensicherheit sorgen (der Preis dafür ist geringe Geschwindigkeit sowie geringere Nettonutzinhalt der Partition), oder für höhere Zugriffsgeschwindigkeit (der Preis dafür die eine höhere Ausfallwahrscheinlichkeit), das alles jedoch unterhalb der Dateisystem-Ebene. Ich finde Software-RAID optimal, da das ganze Array von einem Mainboard auf ein anderes umgezogen werden kann. Auch von einem Kernel zu einem neueren. Es ist kein spezieller Controller nötig, der 2fach vorgehalten werden muss. Hier einige ausgesuchte Details - Infos ...

Es gibt verschiedene RAID-Level: (Am besten finde ich dazu die Dokumentation im Wiki: https://de.wikipedia.org/wiki/RAID)
Mein Lieblingslevel ist eindeutig RAID6, hier eine Erklärung wie RAID6 bei 4 Platten organisiert ist:

wie funktioniert RAID6 mit 4 Platten genau?

Evolution von einer "realen Partition" zur "simulierten"

Festplatten sind "Block"-Devices:
- Erst mal betrachten wir Festplatten als "Block" Devices
- Ihre Kapazität ist "n" Sektoren, somit kann die Platte n * ~SectorSize~ Bytes speichern
- Früher hatten Festplatten 512 Bytes Sektorgrösse, heute sind es oft 4096 Byte (=4K)
- Ein "Sektor" ist hier die kleinste Datengruppe die adressiert danach gelesen oder geschrieben werden kann
- Will man ein Byte lesen, so wird man physikalisch immer den ganzen Sektor lesen müssen.
- Daraus ergibt sich ein Hintergrundwissen: Habe ich ein Byte gelesen, sind die restlichen 4095 Bytes im Cache

RAID-Arrays sind (auch nur) "Block"-Devices:
- Beim Übergang auf RAID wird diese Datengruppierung noch massiver
- Ein RAID - Chunk hat z.B. die Größe von 512K also 128 Sektoren zu 4096 Byte (128*4K=512K)
- Ein Stripe hat bei 4 RAID-Devices 4 Chunks, D0+D1+P(0,1)+Q(0,1) = 4 MByte brutto = 2 MByte netto
- Jeder Block hat natürlich eine "Adresse", die sind einfach durchnummeriert von "0" bis "n-1"

Rolle des Dateisystem

Ein Dateisystem braucht einfach nur eine Block-Device, darauf bildet es Dateien und Ordner und Zugriffsrechte ab.
Das Dateisystemsystem sieht einfach nur die Partition "/dev/md0", hier ist die Welt in Ordnung: einfach eine Kette blauer Nutzdatenblöcke, hier nur von "0" bis "5" dargestellt, das geht natürlich in Wirklichkeit viel weiter. Eine 1 TB Platte hätte z.B. Blöcke von "0" bis "488280".

"md" schneidet die linear angeordnete Partion in Streifen

4 Platten im RAID6-Verbund, ein Block=Chunk sei 512K lang.
- md bezeichnet Block auch auch als "Chunk" oder "Strip"
Also 2 Blöcke mit Nutzdaten "D" (die beiden Datenblöcke mit den Adressen "0" und "1") verteilt md auf alle 4 Platten. Oben sieht man die "0". darunter die "1". dann die Parität "P(0,1)". dann die Parität "Q(0,1)". Dies ist ein Stripe, also ein Streifen (vertikal betrachten!).
- Platte "0": bekommt direkt den Block "0"
- Platte "1": bekommt direkt den Block "1"
- Platte "2": md berechnet aus "0" und "1" einen neuen Blockinhalt mithilfe der magischen Funktion "P"
- Platte "3": md berechnet aus "0" und "1" einen neuen Blockinhalt mithilfe der magischen Funktion "Q"
Ein Stripe (ein Streifen) ist also immer 1 MByte gross (Nutzdaten D0 + D1). Das ist die Minimale atomare Grösse die ein RAID Array schreiben kann. Wird also nur 1 Byte einer Datei geändert muss md 1 Mbyte neu schreiben. Es kann also sein dass das Byte in D0 liegt -> D0 muss neu geschrieben werden, D1 kann bleiben, P und Q Muss neu geschrieben werden. 3 Chunks werden geschrieben: D0, P und Q -> 1,5 MByte.
P und Q sind zwei Funktionen, die keine kurze Prüfsumme bilden, sondern wiederum eine Bitfolge mit genau der Länge eines ganzen Blockes. Die mathematischen Routinen sind dabei so geschickt gewählt dass die Ergebniswerte von P und Q eindeutig mit dem Inhalt von "0" und "1" zusammenhängen. Ändert sich also nur ein Bit in "0" oder "1", so ändert sich auch entsprechend der Wert von "P" und "Q".
P und Q werden rotierend angeordnet damit keine reinen Paritätsplatten entstehen
P und Q verwenden unterschiedliche Algorithmen. Aber beide Routinen brauchen die Blöcke "0" und "1" als Eingangsparameter.
P ist ein einfaches XOR aller Daten Chunks

#
#  das Original ist in den Kernel Sourcen unter "md\lib\raid6\int.uc"
#
#  Copyright 2002-2004 H. Peter Anvin - All Rights Reserved
#
//
// Pascalversion (c) Andreas Filsinger 
// 
function P(D : Array of TStrip) : TStrip;
var
 n : Byte;
begin
 P := D[High(D)];
 for n := High(D)-1 downto 0 do
  P := P xor D[n];
end;

Q ist komplizierter Reed-Solomon-Code, bzw ein Galois Field, GF(2 hoch 8), (dadurch begründet sich übrigens die RAID6 Limitierung auf 253 Disks):

#
#  das Original findet man in den Kernel Sourcen unter "md\lib\raid6\int.uc"
# 
#  Copyright 2002-2004 H. Peter Anvin - All Rights Reserved
#  
// 
// Pascalversion (c) Andreas Filsinger 
// 
function Q(D : Array of TStrip): TStrip;
var
 n : Byte;
 T1, T2 : TStrip;
begin
 Q := D[High(D)];
 for n := High(D)-1 downto 0 do
 begin

  //
  //  The MASK() operation returns $FF in any byte for which the high
  //  bit is 1, $00 for any byte for which the high bit is 0.
  // 
  T2 := MASK(Q);

  //
  // The SHLBYTE() operation shifts each byte left by 1, *not*  
  // rolling over into the next byte
  //
  T1 := SHLBYTE(Q);

  //
  // The NBYTES() operation returns a TStrip filled with the given
  // byte 
  // 
  T2 := T2 and NBYTES($1D);

  T1 := T1 xor T2;
  Q := T1 xor D[n];
 end;
end;

- P und Q werden in Wirklichkeit auf einen Rutsch in einer Funktion names "gen_syndrome". Diese liegt mehrfach implementiert vor: Verschieden optimiert für spezielle CPU Technologien z.B. für NANO (ARM), oder MMX, MMX2, AVX2 (AMD/Intel).

Ausfallüberlegungen

der Ausfall einer einzelnen Platte ist uns zu einfach (der Wert P wird benutzt!): wir nehmen immer 2 gleichzeitige Ausfälle an:
Jetzt müssen wird ganz stark sein: Wenn wir nichts mehr haben (also die beiden Platten die "0" und "1" beherbergen), also nur noch "P" und "Q" können wir daraus "0" und "1" rekonstruieren.
die Partitionen "2" und "3" fallen aus: Ähm, null-Problem: Wir haben kein Datenverlust Block #0 und #1 sind doch noch da! Und P und Q neu zu berechnen? Das machen wir jeden Tag millionenfach! Also ist die Rekonstruktion einfach!
die Partitionen "0" und "1" fallen aus: da "P" und "Q" zur Verfügung stehen lässt sich "0" und "1" zurückrechnen.
die Partition "0" und "P" fallen aus. Aus Q und "1" lässt sich "0" berechnen, danach können wir wieder "P" rekonstruieren
die Partition "0" und "Q" fallen aus. Aus P und "1" lässt sich "0" berechnen, danach können wir wieder "Q" rekonstruieren

Das Tool unter Linux heisst mdadm, und es ist überall gut dokumentiert

http://www.ducea.com/2009/03/08/mdadm-cheat-sheet/

Tipps

Benutze eine eigene Platte (SSD) für Boot und Betriebssystem. Es gibt natürlich auch die Möglichkeit vom RAID Array zu booten, oder Swap oder Systempartitionen darauf zu haben, aber das ist NICHT zu empfehlen weil es auch mit Risiken verbunden ist (Wenn das vermischt wird schwächst Du die Datensicherheit, Gefahr bei Updates, Mobilität). Betrachte dein RAID Array als Verbund, den man auch mal komplett an neue Hardware anschliessen können muss.
Benutze Level 5 (ab 3 Partitionen) für Grössen bis 5GB oder Level 6 (ab 4 Partitionen) ab 5 GB
Benutze ein Bitmap (das ist default!), aber kein externes (dadurch schwächst Du die Datensicherheit, Stichwort Mobilität des RAID)
Benutze Platten mit nahezu gleicher Grösse und Datenrate
Wenn eine Platte leicht oder sehr viel grösser ist als die anderen im Verbund. Erstelle dennoch eine maximal grosse Partition. Wenn die kleinen Platten in Zukunft alle ausgefallen / ausgetauscht sind kannst Du mit --grow die RAID Partition auch vergrössern und so den zunächst ungenutzen Platz dennoch nutzen.
Benutze Platten verschiedener Hersteller, oder verschiedene Modelle / Serien, oder verschiedene Chargen Nummern. Dies erhöht die Diversität des Ausfallmomentes.
Mache Firmware-Updates aller Platten auf einem Windows PC vor dem Einbau
Bei einer Wartung kann die SATA Verkabelung völlig vertauscht werden, kein Problem!
Versuche zumindest einen SATA Port freizulassen, hier kann bei einem Plattentausch die "Neue" angeschlossen werden, ohne dass man eine bestehende Platte abziehen muss (Ja, man kann und sollte im reibungslos laufenden Betrieb mal eine (alte) Platte tauschen!!). Optimal sind z.B. 6x SATA Ports: 1x System 4x RAID6 1x frei
Mache Dir eine Lageplan-Skizze der Platten mit folgenden Angaben:
- Lage der Platte (aus der Skizze ersichtlich)
- SATA Port Bezeichnung (z.B. "Rot"-"0", ermitteln durch Aufdruck auf dem Mainboard)
- Plattenbezeichnung (z.B. "/dev/sdb", ermitteln durch hwinfo --hdd)
- "Serien-Nummer" der Platte (z.B. "GDCCBSGGS", ermitteln durch smartctl -a /dev/sdb)
- Nummer der Platte inerhalb des RAID-Verbundes (z.B. "3", ermitteln mdadm --detail /dev/md0)

Inbetriebnahme eines neuen RAID Verbundes

Hardware

SATA - Controller

Vorrangig nutze ich die OnBoard SATA 6 Gb/s Schnittstellen, eine lasse ich frei für Recovery Szenarien
Nach einigem Herumprobieren mit Storage-Controllern setzte ich auf PCIe Karten mit Marvell Chipsatz, hier gab es für mich (unter Linux) keinerlei Probleme
Man muss die RAID Funktion der Controller ja nicht nutzen (gilt für 88SE9220 und 88SE9230)
Es gibt immer auch Varianten ohne RAID, (88SE9235 und 88SE9215)

RAID - Controller

(deren RAID Funktion ich natürlich nicht nutze!)

StarTech PEXSAT32
http://www.dawicontrol.de/ (etwas teuer aber aus Deutschland)
- DC-624e RAID (Marvell 88SE9230)
- 2 Sachen stören mich: die beiden eSATA Ports, keine nonRAID (88SE9235) Version verfügbar
HighPoint RocketRAID 640L (RR640L, 88SE9230 laut Prospekt, in Wirklichkeit 88SE9235)
MegaRAID® SAS 9271-4i (https://www.broadcom.com/products/storage/raid-controllers/megaraid-sas-9271-4i)
MegaRAID® SAS 9270-8i (https://www.broadcom.com/products/storage/raid-controllers/megaraid-sas-9270-8i)
MegaRAID® SAS 9271-8i (https://www.broadcom.com/products/storage/raid-controllers/megaraid-sas-9271-8i)
Startech PEXSAT34RH (https://www.startech.com/Cards-Adapters/HDD-Controllers/SATA-Cards/4-Port-PCI-Express-SATA-6Gbps-RAID-Controller-Card~PEXSAT34RH)
- basiert auf 88SE9230

NonRAID - Controller (auch JBOD)

syba SI-PEX40062 (Marvell 88SE9235, NonRAID)
- IO Crest SI-PEX40062
- IO Crest SI-PEX40057
HighPoint Rocket 640L (R640L, Marvell 88SE9230, NonRAID)
http://www.iocrest.com
- IO-PCE9235-4I (Marvell 88SE9235, NonRAID, 2x Lane)
- IO-PCE9215-4I (Marvell 88SE9215, NonRAID, 1x Lane)

Super - Aber nicht verfügbar

88SE9345 PCIe 2.0 x4 -> 4x SATA 6 Gbps
88SE1475 PCIe 3.0 x8 -> 16x SATA 6 Gbps
88SE1337 PCIe 3.0 x4 -> 8x SATA 6 Gbps

-> Doch verfügbar? -> andreas(.)filsinger(@)orgamon(.)org

Im Test

Exsys EX-3508 PCIe - 1x Slot - 1 Lane -> 8x SATA (Silicon Image SIL3132)
- Läuft direkt unter Linux ohne Problem
- Er hat 2 "echte" SATA-Ports a 3 Gb/s, diese werden auf 4 Ports per "Port Multiplier" gemultiplext also nominal 1.5 GB/s, effektiv weniger
- Testergebnis: Funktioniert - jedoch die einzelnen Platten können nur langsam angesprochen werden
Exsys EX-3516 PCIe - 2.0 2x -> 4x SATA (Marvell 88SE9230)
- Läuft direkt unter Linux ohne Problem
- Erkennt alle Platten mit 6 Gbps
- Ein Jumper deaktiviert das BIOS (was ja in meinem Fall sinvoll wäre), wenn man aber beim Linux Betrieb auf das BIOS verzichtet wird die Karte überhaupt nicht mehr erkannt
- In Ruhe ist per LED und per Geräusch aktivität an den Platten zu bemerken, keine Ahnung was der hier macht (hat nix mit md zu tun!!!)
- (Fazit: Durchgefallen)
HighPoint Rocket 640L (Marvell 88SE9230)
- komisch, auf dem Marvell Chip steht 88SE9230 es sollte aber laut Marvell ein 88SE9235 sein?! Es ist scheinbar so, dass Marvel hier die Politik geändert hat (nonRAID=88SE9230, RAID=88SE9235)
- Tatsache ist dass das Board-Layout zwischen RR640L und RR640L völlig identisch ist.
- Läuft direkt unter Linux ohne Problem
- Erkennt alle Platten mit 6 Gbps
- Nicht mehr BIOS als notwendig, keine LEDs, keine Jumper
- Fazit: Testsieger
- 29.10.2016: Ausfall des Controllers, ev. auch verursacht durch Update auf openSuSE 42.2
  - die 4 (der 8) angeschlossenen Disks wurden aus dem Array rausgeworfen
  - das Array wurde auf "inactive" gesetzt
  - nach "--run" kamen i/o Errors!
HighPoint RocketRaid 640L (RR640L, Marvell 88SE9235)
- identisches Board-Layout im Vergleich zu R640L, jedoch mehr Bestückung:
- onboard Buzzer
- Nuvoton Microcontroller
- I2C Bus Jumper
- diverse Probleme:
  - Bootet nicht mehr bei 2 Boards, musste auf einem alten Board teste
  - weder im nonRAID noch in RAID Modus wird es von Linux erkannt
  - openSUSE Treiber greifen fix auf eine bestimmte Kernel-Version zu, setup misslingt
- Fazit: Unbrauchbar
Adaptec HBA 1000-8i
- 3. Gen PCIe 8x
- 2 Ports á 4x SATA á 3 Gbp/s
- 2 Ports á 12 Gbp/s
- Muss aktiv angeblassen / gekühlt werden sonst wird sie zu heiss
- Funktioniert nativ unter Linux openSUSE 41.2
- Fazit: solide
Startech PEXSAT34RH
- Test ab 20.01.2017,
- bestanden funktioniert ohne Probleme
AOC-SAS2LP-MV8
- Würde ich gerne testen, ca. 183 Euro bei jacob

HDD-Bunch: loser Versuchsaufbau

Hier 4x 1 Terrabyte Festplatten von 2 unterschiedlichen Herstellern (2x ST1000NM0011, 2x WD1003FBYX) im Software RAID 5 Verbund
Zum Booten und für das openSuSe 11.4 System verwende ich eine Intel SSD
Man sieht im Versuchsaufbau die 4 Festplatten auf übergrosse Kühlkörper geschraubt

HDD-Bunch: 19" Eigenkonstruktion für Produktivbetrieb

6x HotSwap Wechselrahmen auf einem 19" Träger

Die Wechselrahmen sind ohne Temperaturkühlung passiv (Bin nicht so 100% zufrieden, werden durch ICY DOCK ersetzt)

Mit den 6x ICY DOCK MB171SP-B (http://www.icydock.de/goods.php?id=142) ist das wesentlich besser
- aktive Kühlung der Platte durch einen Lüfter -> Temperaturen < 42 °C
- Front LED blau, erleichtert die Identifikation der Platte

Download der Frontplatte : http://cargobay.orgamon.de/NAS-0001-0001.fpd (fräst die Schaeffer AG Berlin)
Man braucht noch 3x 2 Winkel: http://www.caselabs-store.com/flex-bay-5-25-device-mount-hd/

Software

HDD-Partition(en) erstellen

Pro Platte des Verbundes: eine maximal grosse Partition
Auf allen RAID Platten des Verbundes: Erstelle eine Primäre sowie Maximal grosse Partition Typ xFD00 (=Linux RAID autodetect)
Es spielt keine Rolle ob eine DOS-Partitionstabelle (fdisk) oder eine GPT-Partitionstabelle (gdisk) erstellt wird, gdisk ist Stand der Technik (2016)
Bei OpenSuse verwende ich gerne
- gdisk /dev/sdb
- i <ENTER>
- n <ENTER>
- <ENTER> <ENTER> <ENTER> fd00 <ENTER>
- <w> <ENTER>
- <y> <ENTER>
- <ENTER>

die "virtuelle" RAID-Partition erstellen

Erstelle eine raid-6-Partition aus den Einzelnen
- mdadm --create --verbose /dev/md0 --level=6 --raid-devices=5 /dev/sd[bcdef]1

Nicht erschrecken, direkt nach dem Erstellen eines RAID5 Verbundes ist da einige Zeit ein "Spare" Drive, das verschwindet aber wenn das Array vollständig erzeugt ist. Schon in dieser Phase kann das Array benutzt also beschrieben werden.
- http://www.spinics.net/lists/raid/msg34976.html

etx4 Dateisysten erstellen

Erstelle ein Filesystem auf der raid-Partition
mkfs.ext4 -m 0 -O 64bit /dev/md0
- "-m 0": da die Platte NICHT unsere Systemplatte ist soll für root nichts reserviert werden
- "-O 64bit": sollte die aktuelle Partition < 16 TB sein, würde kein Dateisystem erstellt, das auf über 16 TB erweiterbar ist. Um diese Situation nach möglicher Erweiterung des Arrays zu vermeinden, wird mkfs gezwungen den >16TB Support von Anfang an zu aktivieren. Zu beachten sind dabei 2 Dinge:
  - die Defaults aus /etc/mke2fs.conf gelten dennoch, wir schalten also nur die 64bit noch dazu
  - ES GIBT KEINEN Migrationsweg von "ext4 OHNE 64bit-Support" auf "ext4 auf eine Partition >16 TB" (Stand 1.42.13, also 03.2016) (Das kann man nicht glauben oder?!)
  - ES GIBT EINEN WEG? eMail an andreas.filsinger at orgamon.org
- Im Internet gibt es Infos, dass ext4 auf den RAID Betrieb hin optimiert werden kann. Das passiert aber im Rahmen der Erzeugung des Systems von alleine. Die manuelle Berechnung ist hier. Es war bei mir aber immer so dass die Werte passten! Hier: http://busybox.net/~aldot/mkfs_stride.html aber der Link für die Berechnung der Werte.
- Ich habe ein ext4 Dateisystem, also vielmehr das darunter liegende md-Device von RAID5 auf RAID6 migriert, dabei habe ich die Plattenanzahl von 4 auf 5 erhöht, dennoch passten die Werte am Ende wieder zusammen.

Einhängen in ein Verzeichnis

Damit wir das rießige ext4 Dateisystem nutzen können müssen wir es an beliebiger Stelle in unser Verzeichnis-System einhängen
- Erstelle dazu ein Verzeichnis (in meinem Fall /srv/smb/ra6)
Unser Array hat Namen "~Hostname~:0", danach ist es als "/dev/md0" sichtbar, das bedeutet die erste (=0) LOKALE md-Partition
- Ändert sich jedoch der Name dieses Hosts (durch DHCP), oder wird das Array auf einen anderen Host umgezogen so ist es nicht mehr "lokal" und es erhält einen Namen wie z.B. "/dev/md127"
- Also Vorsicht vor diesen Alias-Namen beim Mounten: Ich verwende lieber den "uuid" des Arrays selbst, und nicht "lokale" oder "remote" Namen. Diese Bezeichnung ist viel langlebiger (also eigentlich für immer), und stimmt auf jedem System.
- l /dev/disk/by-id | grep md
- ... liefert Dir den passenden Namen
- schau ev. mit mdadm nach, ob die UUID auch richtig/identisch ist:
- mdadm --detail /dev/md127

joe /etc/systemd/system/srv-smb-ra6.mount

[Unit]
Description=srv-smb-ra6

[Mount]
What=/dev/disk/by-id/md-uuid-2ca7d214:9c6bfab4:b2ecf28b:72df44ca
Where=/srv/smb/ra6

[Install]
WantedBy=local-fs.target

Sicherstellen, dass das Array beim Hochfahren gemounted wird:
- systemctl enable srv-smb-ra6.mount
Jetzt endlich einhängen und nutzen:
- systemctl start srv-smb-ra6.mount

Fertig

Nun endlich kann das RAID voll genutzt werden, beschreibe es unter Volllast - egal
- Bedenke aber dass im Hintergrund die Redundanz des RAID aufgebaut wird, ich denke mal in dieser Phase darf nix schiefgehen

Im laufenden Betrieb

Mounten des Dateisystemes

natürlich automatisch beim Systemstart mit einer systemd-Datei:
- Linux.systemd#eines_RAID_Arrays

Montoring

Sync, Reshape

watch -n.4 'cat /proc/mdstat'

Fittness des Array

mdadm --detail /dev/md0

Temperatur einzelner Platten

smartctl -l scttemp /dev/sdX | grep Current

Lesegeschwindigkeit des Array

dd if=/dev/md127 iflag=direct of=/dev/null bs=1M count=4096

Lesegeschwindigkeit einer einzelnen Platte

dd if=/dev/sdc1 iflag=direct of=/dev/null bs=1M count=4096

Infos über RAID und ext4

#
# Welche Platte hängt an welchem SATA-Controller?
#
hwinfo --disk | grep ata
 
#
# Aktueller Status des RAID Verbundes
#
cat /proc/mdstat

# 
# Alle Parameter meines RAID 6
#
mdadm --detail /dev/md0

#
# Alle Infos über den Superblock auf jeder Disk
#
mdadm --examine /dev/sdb1
mdadm --examine /dev/sdc1
mdadm --examine /dev/sdd1
mdadm --examine /dev/sde1
mdadm --examine /dev/sdf1

#
# Alle Parameter meines ext4 Dateisystems
#
tune2fs -l /dev/md0

#
# Alternativer Befehl
#
dumpe2fs /dev/md0

Vollständiger Lesecheck

Siehe auch diese tolle Dokumentation http://www.thomas-krenn.com/de/wiki/Mdadm_checkarray

Vor der Prüfung, lass dir anzeigen wie der Stand der Anzahl der Lesefehler ist

cat /sys/block/md~ArrayNummer~/md/mismatch_cnt

Starte die Prüfung

echo check > /sys/block/md~ArrayNummer~/md/sync_action

Werden Platten zu warm, oder es ist zu viel los kann man den check unterberechen

echo idle > /sys/block/md~ArrayNummer~/md/sync_action

Ist die Prüfung beendet lass Dir anzeigen ob es Lesefehler gab

cat /sys/block/md~ArrayNummer~/md/mismatch_cnt

Identifikation

Machmal kann es schwierig sein die Platte zu identifizieren. Vorausgesetzt der Wechselrahmen hat eine Aktivitäts-LED kann mit folgendem Befehl für maximale (Lese-) Aktivität gesorgt werden. Ev. lässt sich so die Platte erkennen:

dd if=/dev/sdX of=/dev/null

Umzug

Wenn möglich unmounten, um das Array definiert runterzufahren. Stromlos schalten.
Das ganze Array einfach abklemmen, über die SATA-Host-Kanal-Kabel-Reihenfolge keine Gedanken machen.
An den neuen Server anschliessen. Neu starten, im dmesg müsste über die Bildung eines neuen md-devices berichtet sein.
die neue md-Partition mit dem richtigen Filesystem mounten.

Umzug von Kernel 3.0.101-95 nach 3.4.63-2.44 ist ohne Probleme gelungen
Umzug von Kernel 3.4.63-2.44 nach Kernel 4.1.10-1 ist ohne Probleme gelungen

Hot Plug

Bei SATA ist Hotplug kein Feature irgendeiner extra Elektronik, sondern die Fähigkeit der Platten & Stecker selbst!
Physikalisch sind die Kontaktzungen verschieden lang ausgeprägt, also elektrisch werden einige Kontakte später als andere erreicht, das ermöglicht ein stufenweises Hochfahren der Elektronik oder der Signalisierung. Also nicht die Kabel rein und raus wie ein wilder Stier, sondern schön langsam mit Gefühl. Dabei die Stecker immer plan aufstecken, nicht schief, an einer Ecke zuerst und dann reinwuchten. Du bist jetzt der Caddy, der sauber und plan einlochen sollte.
- Beim Anschluss einer neuen Platte: Zuerst Strom, dann Datenkabel dranstecken.
- Beim Ausbau einer alten Platte: Zuerst Datenkabel, dann Stromkabel abziehen.

Probleme und deren Lösung

Im folgenden Fallbeispiele was alles in der Praxis schiefgehen kann

Ausfall eines Strom-Stranges

Ich hatte einen Ausfall folgender Art: An einer Stromversorgung hingen 3 Platten: 2 eines RAID 6 Verbundes (zum Glück RAID 6!), und eine SSD. Die 2 magnetischen Platten waren plötzlich weg, die SSD jedoch noch da! Ich dachte erste an ein Problem an den beiden SATA Kabeln, aber es war ein Ausfall (Wackler) des 12 Stranges. Der SSD war das egal, da sie scheinbar nur den 5 Volt Part des Kabels benutzt (der 3.3 Volt Part war gar nicht angeschlossen! Früher war das mal Teil der Norm - heutzutage werden die 3.3 V nicht mehr benutzt). OK in der Panik habe ich eine der 2 Platten getauscht , mit dem Ergebnis dass diese nicht in dmesg sichtbar war. Ich kan nun auf die Idee mit den 12 Volt und konnte den Wackler beheben. Eigentlich sofort war die eine (alte) Platte nach einem --add wieder im Verbund, die neue Platte musse ich erst passend partionieren, dann mit --add, dann machte er einen resync.

(Folgendes Dokumentation bezieht sich auf "einfach mal eine Platte rausgezogen! Natürlich im laufenden Betrieb.")

Das Dateisystem hat davon gar nix gemerkt, eigentlich ohne sichtbaren Performanche-Verlust weitergeschrieben
Die mdadm --detail sah schon traurig aus:

   Number   Major   Minor   RaidDevice State
      0       8       49        0      active sync   /dev/sdd1
      2       0        0        2      removed
      2       8       81        2      active sync   /dev/sdf1
      4       8       17        3      active sync   /dev/sdb1
      5       8       33        4      active sync   /dev/sdc1

OK, einfach neue Platte rein.
Im "dmesg" erkannt dass es als "/dev/sde" eingetragen wurde
Das war so eine "recycelte Platte" mit 5 Partitionen, erst mal im Yast alle gelöscht und EINE grosse RAID Partition erstellt
Ein einziger Befehl reichte, um das Array wieder komplett zu machen:
- mdadm --manage /dev/md127 --add /dev/sde1

Im mdadm --detail sah es nun besser aus:

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

Nach 180 Minuten war wieder alles gut!

Ausfall eines Controllers

Noch nicht abschliessend geklärt ist, ob ein Controller nicht mehr vom Kernel unterstützt wurde
oder ob der Controller hardwaremäßig ausgefallen ist
oder ob der PCIe Bus plötzlich defekt wurde

4 von 8 Platten eines RAID6 Arrays waren weg, das Array inaktiv
Da das Array nicht wichtig war habe ich es neu erstellt
"--run" brachte eher Probleme
"--re-add" brachte letztendlich auch wieder ein inaktives Array

Grow wird verweigert

Erster Versuche (ohne Erfolg)

tokio:~ # mdadm /dev/md127 --grow --raid-devices=8
mdadm: Failed to initiate reshape!
unfreeze

Zweiter Versuch (mit dem Erfolg)

tokio:~ # mdadm /dev/md127 --grow --raid-devices=8 --backup-file=/root/mdadm_backup-file
mdadm: Need to backup 15360K of critical section..

Reshape hängt bei 0.0%

reshape hängt bei 0.0% : Erst ein "Nachtreten" half

echo max > /sys/block/md127/md/sync_max

nun erst gings los ...

die 64bit - Falle des Ext4

Ein ohne besondere Parameter frisch angelegtes ext4 Dateisystem hat einen grössen Beschränkubg von 16 TB. Erst das 64bit Flag, das beim Anlegen des Dateisystems gesetzt werden muss ermöglicht mehr als 16 TB. Es gibt keinen Weg ein befülltes 16 TB Dateisystem auf 64Bit zu migrieren.
Partition Size

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048      7814035455   3.6 TiB     FD00  primary

nach dem reshape kam

[72254.324630] md: md127: reshape done.
[72256.830962] RAID conf printout:
[72256.830966]  --- level:6 rd:7 wd:7
[72256.830969]  disk 0, o:1, dev:sde1
[72256.830970]  disk 1, o:1, dev:sdd1
[72256.830972]  disk 2, o:1, dev:sdc1
[72256.830973]  disk 3, o:1, dev:sdb1
[72256.830975]  disk 4, o:1, dev:sdg1
[72256.830976]  disk 5, o:1, dev:sdf1
[72256.830977]  disk 6, o:1, dev:sda1
[72256.830982] md127: detected capacity change from 8001301774336 to 20003254435840
[72259.591900] VFS: busy inodes on changed media or resized disk md127

also hatte ich anstelle der 8 TB nun 20 TB, dann kam der grosse Schock

1)

resize2fs /dev/md127
resize2fs 1.42.11 (09-Jul-2014)
resize2fs: New size too large to be expressed in 32 bits

Also der Resize ist NICHT möglich da bei der Erstellung des Filesystems die 64bit Option nicht gesetzt wurde.

2)

tune2fs -l /dev/md127
tune2fs 1.42.11 (09-Jul-2014)
Filesystem volume name:   <none>
Last mounted on:          /srv/smb/ra6
Filesystem UUID:          2fb00d07-5394-4bc5-8f7d-cdaf5ea90d17
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              244183040
Block count:              1953442816
Reserved block count:     0
Free blocks:              227623471
Free inodes:              236320173
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      558
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         4096
Inode blocks per group:   256
RAID stride:              128
RAID stripe width:        256
Flex block group size:    16
Filesystem created:       Sun Nov  8 00:32:48 2015
Last mount time:          Mon Mar  7 16:30:20 2016
Last write time:          Mon Mar  7 16:30:20 2016
Mount count:              21
Maximum mount count:      -1
Last checked:             Sun Nov  8 00:32:48 2015
Check interval:           0 (<none>)
Lifetime writes:          12 TB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      95862d26-1883-4880-b221-ee78f166846f
Journal backup:           inode blocks

meine Lösung war: Daten sichern, mkfs neu machen mit der 64bit Option, Daten rücksichern
Dokumentation entsprechend geändert!: IMMER DAS 64bit FEATURE SCHON VON ANFANG AN EINSCHALTEN AUCH BEI KLEINEN PARTITION BEI DENEN EIN WACHSEN ZU ERWARTEN IST

tune2fs 1.42.11 (09-Jul-2014)
Filesystem volume name:   <none>
Last mounted on:          /srv/smb/ra6
Filesystem UUID:          f0362f20-bf7a-4e6b-9be3-9e3626488036
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              305225728
Block count:              4883607040
Reserved block count:     0
Free blocks:              4864141337
Free inodes:              305225717
First block:              0
Block size:               4096
Fragment size:            4096
Group descriptor size:    64
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         2048
Inode blocks per group:   128
RAID stride:              128
RAID stripe width:        640
Flex block group size:    16
Filesystem created:       Tue Mar  8 15:31:09 2016
Last mount time:          Tue Mar  8 15:41:14 2016
Last write time:          Tue Mar  8 15:41:14 2016
Mount count:              1
Maximum mount count:      -1
Last checked:             Tue Mar  8 15:31:09 2016
Check interval:           0 (<none>)
Lifetime writes:          165 MB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      7d24e40b-9935-4dec-8d4d-7dfa965f5942
Journal backup:           inode blocks

/dev/md127       19T  1.3T   17T   8% /srv/smb/ra6

Hinzufügen einer Platte zur Kapazitätserhöhung

Im RAID6 dient die Kapazität von 2 Platten allein der Paritätsspeicherung (Die Parität ist dabei über alle Platten verstreut, die Aussage bezieht sich nur auf die Kapazitätsanforderungen der Parität).
Ist diese feststehende Anforderung des RAID6 erfüllt, dient jede weitere Platte der echten Kapazitätserhöhung. Also ist ein Ausbau von 4 Platten auf 5 Platten besonders lukrativ.
Alle folgenden Aktionen wurden im laufenden Betrieb durchgeführt (RAID6, bisher 4 Platten, ext4 ist die ganze Zeit gemounted).

neue Platte, die eine Kapazität von >="device Size" haben muss hinzustecken
im kernel log sehen ob die Platte sauber hinzugefügt wurde
- dmesg
- Link Speed wie erwartet? In meinem Fall "6 Gbps"
- in meinem Fall war der neue Device /dev/sdf
mit gdisk eine maximale "Linux RAID" - Partition erstellen
- gdisk
- sicherstellen das es keine Partitionen bisher gibt:
- i
- "No paritions" (Gut!)
- n
- Partition number (1-128, default 1): <ENTER>
- First sector (34-5860533134, default = 2048) or {+-}size{KMGTP}: <ENTER>
- Last sector (2048-5860533134, default = 5860533134) or {+-}size{KMGTP}: <ENTER>
- Current type is 'Linux filesystem'
- Hex code or GUID (L to show codes, Enter = 8300): fd00
- Changed type of partition to 'Linux RAID'
- Command (? for help): w
Platte dem md bekanntmachen und dann dem Verbund einverleiben
- mdadm --manage /dev/md0 --add /dev/sdf1
- Optional: Cache Size erhöhen (war bei mir nur 513 groß)
- echo 32768 > /sys/block/md0/md/stripe_cache_size
- mdadm /dev/md0 --grow --raid-devices=5 --backup-file=/root/mdadm_backup_4_devices
- das nun folgende und technisch notwendige "reshape" geht sehr lange (bei mir 18 Stunden) und man muss warten, bis die neue Kapazität zur Verfügung steht
- bleibt das reshape bei 0.0% stehen siehe Kapitel "Ausfall"
Man erfährt dies z.B. über dmesg

[159744.821671] md: md0: reshape done.
[159746.036346] RAID conf printout:
[159746.036349]  --- level:6 rd:5 wd:5
[159746.036351]  disk 0, o:1, dev:sdb1
[159746.036352]  disk 1, o:1, dev:sdd1
[159746.036352]  disk 2, o:1, dev:sde1
[159746.036353]  disk 3, o:1, dev:sdc1
[159746.036354]  disk 4, o:1, dev:sdf1
[159746.036357] md0: detected capacity change from 4000527155200 to 6000790732800

erst danach das Dateisystem (kann gerne gemounted bleiben!) erweitern
- resize2fs /dev/md0

Vorsorglicher Austausch einer Platte

Dazu ist es von Vorteil, wenn man eine weitere SATA Schnittstelle im System frei hat. An diesen neuen Port hängt man die neue Platte. Nach dem Neustart schaut man mit hwinfo --disk wie der Devicename von Linux für die neue Platte vergeben wurde (Oder bei Hotswap mit dmesg).

Die neue Platte: Eine maximal grosse Linux-RAID Partition erstellen (mache ich mit yast)

Die neue Partition der neuen Platte muss man bekannt machen
- mdadm /dev/md0 --manage --add-spare /dev/sdd1

Die alte Partition muss ausgetauscht werden
- mdadm /dev/md0 --replace /dev/sde1

Nun erfolgt die resync-Phase
- watch -n.4 'cat /proc/mdstat'

Personalities : [raid6] [raid5] [raid4]
md0 : active raid6 sdd1[4](R) sdc1[1] sde1[2] sdb1[0] sdf1[3]
      976504832 blocks super 1.2 level 6, 512k chunk, algorithm 2 [4/4] [UUUU]
      [==========>..........]  recovery = 53.3% (260476332/488252416) finish=59.5min speed=63787K/sec
      bitmap: 0/4 pages [0KB], 65536KB chunk

unused devices: <none>

Man erkennt dass RAID-Device "2" (rot) durch "2" (grün) ersetzt wird

mdadm --detail /dev/md0

/dev/md0:
       Version : 1.2
 Creation Time : Wed Jan 28 22:47:57 2015
    Raid Level : raid6
    Array Size : 976504832 (931.27 GiB 999.94 GB)
 Used Dev Size : 488252416 (465.63 GiB 499.97 GB)
  Raid Devices : 4
 Total Devices : 5
   Persistence : Superblock is persistent

 Intent Bitmap : Internal

   Update Time : Mon Mar 30 17:49:32 2015
         State : active, recovering
Active Devices : 4
Working Devices : 5
Failed Devices : 0
 Spare Devices : 1

        Layout : left-symmetric
    Chunk Size : 512K

Rebuild Status : 55% complete

          Name : raib23:0  (local to host raib23)
          UUID : a9b9721a:7da8602e:313975c3:10fa337e
        Events : 5132

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

Beobachte während des Resync die Temperatur aller Platten.
- Dies mache ich durch folgendes Script:

#!/bin/bash

echo "b:"
smartctl -A /dev/sdb | grep "Temperature_Celsius "
smartctl -A /dev/sdb | grep "Power_On_Hours "
echo "c:"
smartctl -A /dev/sdc | grep "Temperature_Celsius "
smartctl -A /dev/sdc | grep "Power_On_Hours "
echo "d:"
smartctl -A /dev/sdd | grep "Temperature_Celsius "
smartctl -A /dev/sdd | grep "Power_On_Hours "
echo "e:"
smartctl -A /dev/sde | grep "Temperature_Celsius "
smartctl -A /dev/sde | grep "Power_On_Hours "
echo "f:"
smartctl -A /dev/sdf | grep "Temperature_Celsius "
smartctl -A /dev/sdf | grep "Power_On_Hours "
echo "g:"
smartctl -A /dev/sdg | grep "Temperature_Celsius "
smartctl -A /dev/sdg | grep "Power_On_Hours "
echo "h:"
smartctl -A /dev/sdh | grep "Temperature_Celsius "
smartctl -A /dev/sdh | grep "Power_On_Hours "

Kommt es zu Temperaturen>=50°C sollte man einschreiten

190 Temperature_Celsius 0x0032   071   056   000    Old_age   Always       -       29
190 Temperature_Celsius 0x0022   072   072   045    Old_age   Always       -       28 (Min/Max 26/28)
190 Temperature_Celsius 0x0022   071   069   045    Old_age   Always       -       29 (Min/Max 28/29)
190 Temperature_Celsius 0x0022   055   048   045    Old_age   Always       -       50 (Min/Max 45/51)
190 Temperature_Celsius 0x0022   062   059   045    Old_age   Always       -       38 (Min/Max 38/41)

Vermindere die Sync-Leistung massiv ggf. so lange bis die Platten wieder unter 45 Grad sind, durch

echo 5000 > /sys/block/md0/md/sync_speed_max

# alternativ
#
# sysctl -w dev.raid.speed_limit_max=5000

es wird wohl schwer sein ein gutes Mittelmass zu finden, bei mir war es

echo 60000 > /sys/block/md0/md/sync_speed_max

Full speed ist ja

echo 200000 > /sys/block/md0/md/sync_speed_max

Erst nachdem der Resync durch ist, steht die auszubauende Platte auf (F)

# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid6 sdd1[4] sdc1[1] sde1[2](F) sdb1[0] sdf1[3]
     976504832 blocks super 1.2 level 6, 512k chunk, algorithm 2 [4/4] [UUUU]
     bitmap: 0/4 pages [0KB], 65536KB chunk

unused devices: <none>

# mdadm --detail /dev/md0
/dev/md0:
       Version : 1.2
 Creation Time : Wed Jan 28 22:47:57 2015
    Raid Level : raid6
    Array Size : 976504832 (931.27 GiB 999.94 GB)
 Used Dev Size : 488252416 (465.63 GiB 499.97 GB)
  Raid Devices : 4
 Total Devices : 5
   Persistence : Superblock is persistent

 Intent Bitmap : Internal

   Update Time : Mon Mar 30 18:59:42 2015
         State : active
Active Devices : 4
Working Devices : 4
Failed Devices : 1
 Spare Devices : 0

        Layout : left-symmetric
    Chunk Size : 512K

          Name : raib23:0  (local to host raib23)
          UUID : a9b9721a:7da8602e:313975c3:10fa337e
        Events : 5136

   Number   Major   Minor   RaidDevice State
      0       8       17        0      active sync   /dev/sdb1
      1       8       33        1      active sync   /dev/sdc1
      4       8       49        2      active sync   /dev/sdd1
      3       8       81        3      active sync   /dev/sdf1

      2       8       65        -      faulty   /dev/sde1

Nun muss man dieses noch aus dem Array entfernen
- mdadm /dev/md0 --remove /dev/sde1
Die Platte selbst trägt noch die Signatur für dieses RAID-Array, um Verwirrung auszuschliessen sollte der Superblock gelöscht werden
- mdadm --zero-superblock /dev/sde1
Wer will kann die Platte vor dem Entsorgen noch komplett nullen, andernfalls sollte die Platte mechanisch zerstört werden
- shred -v -z --iterations=0 /dev/sde

RAID insgesamt vergrößern

Im obigen Schritt habe ich EINE Platte ausgetauscht. Es ist somit möglich ALLE 512 GB Platten Schritt für Schritt durch 2 TB Platten zu ersetzen. Es gab immer ein "reboot" weil ich Platten entfernen und neue anklemmen musste - aber niemals war ein unmount des Dateisystems nötig.
NAchdem alle Platten neu sind, und auch alle neuen Platten ein "maximale" Partition ausweisen kann man die Kapazität erhöhen
Auch für die folgenden Schritte war kein unmount nötig - alles erfolgte "online" mit ext4 gemountet!

mdadm --grow ausführen, um das Array wachsen zu lassen
- mdadm --grow /dev/md0 --size=max
SOFORT kann man das Dateisystem vergrössern
- resize2fs /dev/md0
Nun noch beobachten was der "grow" verursacht. ext4 merkt davon nix.
- watch -n.4 'cat /proc/mdstat'

Every 0.4s: cat /proc/mdstat                                                   Wed Apr  1 00:15:16 2015

Personalities : [raid6] [raid5] [raid4]
md0 : active raid6 sdd1[7] sdc1[4] sdb1[5] sdf1[6]
      3906764800 blocks super 1.2 level 6, 512k chunk, algorithm 2 [4/4] [UUUU]
      [=====>...............]  resync = 29.3% (573007872/1953382400) finish=327.4min speed=70255K/sec
      bitmap: 3/4 pages [12KB], 262144KB chunk

unused devices: <none>

RAID5 nach RAID6 Migration

Ich hatte 4x 1 TB Festplatten im RAID5 Verbund

Personalities : [raid6] [raid5] [raid4]
md127 : active (auto-read-only) raid5 sdd1[0] sdf1[1] sdb1[4] sde1[2]
      2930277888 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]

unused devices: <none>

Hole dir eine weitere passende Platte (auch wenn es schon 4 Platten sind, was ja die Mindestanforderung ist bei RAID6, braucht RAID6 die neue Platten zwingend für die zusätzliche Parität "Q", die neben der Parität "P" erstellt wird).
mit yast eine maximale Partition erstellen

mdadm /dev/md127 --manage --add /dev/sdc1

Personalities : [raid6] [raid5] [raid4]
md127 : active raid5 sdc1[5](S) sdd1[0] sdf1[1] sdb1[4] sde1[2]
      2930277888 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]

unused devices: <none>

mdadm /dev/md127 --grow --level=6 --raid-devices=5

Personalities : [raid6] [raid5] [raid4]
md127 : active raid6 sdc1[5] sdd1[0] sdf1[1] sdb1[4] sde1[2]
      2930277888 blocks super 1.2 level 6, 512k chunk, algorithm 18 [5/4] [UUUU_]
      [=>...................]  reshape =  5.7% (55685504/976759296) finish=248.1min speed=61864K/sec

unused devices: <none>

Resize des Dateisystems?
- resize2fs /dev/md127
- Ich Dussel! Ich habe durch die Migration doch gar keinen neuen Platz gewonnen, das war mehr so ein Reflex, da ich ja eine neue Platte hinzugefügt habe. Auf meinen Resize-Versuch sagt Linux richtigerweise:

resize2fs 1.42.11 (09-Jul-2014)
The filesystem is already 732569472 blocks long.  Nothing to do!

Wir haben jetzt laut Händlerangabe 5 Terra-Byte. Doch wieviel davon ist im ext4-Dateisystem nun verfügbar? Durch den RAID 6 Level sind das reale 2,7 Terra-Byte.

Das Bild zeigt den ganzen Vorgang wie ihn dmesg gesehen hat. Es beginnt also mit der neuen Partition sdc1, die aber zunächst als "Spare" in dem Array vorhanden ist.
Bei der Migration merkt er, ok ich muss einen reshape durchführen

Benchmarks

Also hier die Messergebnisse mit einem per 1GBit-LAN angebundenen Windows 7 Client. Das Netzwerk ist hier wohl das Limitierende Element.

reale Umsetzungen

Backup Server "raib2" RAID6-2016
Produktiv Server "server" RAID6-2017