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 ...
wie funktioniert das?
- Es gibt verschiedene RAID-Level: (Am besten finde ich dazu die Dokumentation im Wiki: https://de.wikipedia.org/wiki/RAID)
- Festplatten sind "Block"-Devices:
- Ihre Kapazität ist n Blöcke, somit kann die Platte n * ~BlockSize~ Bytes speichern
- Man kann Blöcke fester Grösse (=Datenportionen) (zum Beispiel: Blöcke haben immer 4096 Bytes) von der Festplatte lesen und schreiben. Man kann nicht weniger, aber auch nicht mehr mit einer einzelnen Anfrage lesen oder schreiben.
- Dabei ist die Adressierung wahlfrei, also ich kann sagen gebe mir den Block #26352 und danach den Block #815
- Jeder Block hat natürlich eine "Adresse", die sind einfach durchnummeriert von "0" bis "n-1"
- In der Realität sind die Daten nicht in einem langen "Streifen" mit der Länge "n" gespeichert, da liegt eine etwas andere Geometrie zugrunde.
- Mein Lieblingslevel ist eindeutig RAID6, hier eine Erklärung wie RAID6 bei 4 Platten organisiert ist:
- Das Dateisystemsystem sieht einfach nur /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".
- 4 Platten im RAID6-Verbund, ein Block sei 512K lang.
- md bezeichnet Block auch auch als "Chunk" oder "Strip"
- Also 2 Blöcke mit Nutzdaten (die beiden 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)".
- 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"
- P und Q verwenden unterschiedliche Algorithmen, aber beide Routinen brauchen die Blöcke "0" und "1" als Eingangsparameter.
- 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 ein-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".
Ausfallüberlegungen
- der Ausfall einer einzelnen Platte ist uns zu einfach: 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/
Inbetriebnahme
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)
Hardware
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
Produktiv
- 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
Partition(en) erstellen
- Auf allen RAID Platten des Verbundes: Erstelle eine Primäre sowie Maximal grosse Partition Typ xFD (=Linux RAID autodetect)
- Es spielt keine Rolle ob eine DOS-Partitionstabelle (fdisk) oder eine GPT-Partitionstabelle (gdisk) erstellt wird
- Bei OpenSuse verwende ich gerne die Partitionsverwaltung in ...
yast
System->Partitioner->Hard Disk->sdX->Add(Partition)->Maximum Size->Raw Volume->(x) do not format->0xFD Linux RAID
die RAID-Partition erstellen
- Erstelle eine raid-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
Dateisysten mounten
- Erstelle ein Filesystem auf der raid-Partition
mkfs.ext4 -m 0 /dev/md0
- "-m 0": da die Platte NICHT unsere Systemplatte ist soll für root nichts reserviert werden
- 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.
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
Dateisystem <-> RAID
Das Dateisystem kann es RAID-Verbund leicht machen, oder das Leben auch erschweren. In der Regel geht ein Dateisystem davon aus dass etwas lesen, oder etwas schreiben im Prinzip die gleichen Kosten hat. Wegen der Redundanz hat der Verbund mit "schreiben" jedoch sehr viel höhere Kosten, beim Lesen hingegen kann die Redundanz sogar die Leistung verbessern.
...
Betrieb
Vollständiger Lesecheck
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
Montoring
watch -n.4 'cat /proc/mdstat'
mdadm --detail /dev/md0
smartctl -l scttemp /dev/sdX | grep Current
Identifikation
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 fertig.
- 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
Ausfall
(Ich hatte noch nie einen Ausfall, aber ich hab 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!
Hinzufügen einer Platte
(alles im laufenden Betrieb RAID6, bisher 4 Platten)
- 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 hinzunehmen
mdadm --manage /dev/md0 --add /dev/sdf1
echo 32768 > /sys/block/md0/md/stripe_cache_size
mdadm /dev/md0 --grow --raid-devices=5
- das "reshape" geht sehr lange (bei mir 18 Stunden) und man muss warten, bis die neue Kapazität zur Verfügung steht
- Dateisystem 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 Start schaut man mit hwinfo --disk wie der Devicename von Linux für die neue Platte vergeben wurde.
- 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 /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
smartctl -all /dev/sd[abcdef] | grep Airflow_Temperature
für alle Platten
- Dies mache ich durch
190 Airflow_Temperature_Cel 0x0032 071 056 000 Old_age Always - 29
190 Airflow_Temperature_Cel 0x0022 072 072 045 Old_age Always - 28 (Min/Max 26/28)
190 Airflow_Temperature_Cel 0x0022 071 069 045 Old_age Always - 29 (Min/Max 28/29)
190 Airflow_Temperature_Cel 0x0022 055 048 045 Old_age Always - 50 (Min/Max 45/51)
190 Airflow_Temperature_Cel 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 --manage --remove /dev/sde1
Vergrößern
- Im obigen Schritt habe ich alle 512 GB Platten Schritt für Schritt durch 2 TB Platten ausgetauscht. Es gab immer ein "reboot" weil ich Platten entfernen und neue anklemmen musste - aber niemals war ein unmount des Dateisystems nötig.
- 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
- 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
- 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
Autostart
- mit systemd.mount
- joe /etc/systemd/system/srv-smb-ra6.mount
[Unit] Description=srv-smb-ra6 [Mount] What=/dev/md0 Where=/srv/smb/ra6 [Install] WantedBy=local-fs.target
Hot Plug
- Beim Anstecken: Zuerst Strom, dann Datenkabel dranstecken.
- Beim Abstecken: Zuerst Datenkabel, dann Stromkabel abziehen.
Benchmarks
Also hier die Messergebnisse mit einem per 1GBit-LAN angebundenen Windows 7 Client. Das Netzwerk ist hier wohl das Limitierende Element.