FreeBSD 11.1 -> nvme + sata III ssd + ZFS Mirror

S

Sadakazu

Well-Known Member
Moin moin...
Ein bekannter von mir will sich das grad so richtig ekelig geben...

Der hat nen recht böses Monster an PC sich zusammen gebaut...
Ist von Windows weg weil er es als "schrott" emfpindet und Manjaro/Arch und andere Linux Distris sind ihm zu "schnelllebig" zu "instabil" und er würde gerne ZFS als datei System nutzen, was auf Linux ja recht viele Probleme bereitet da TRIM zb nicht unterstützt wird und nativ sowieso nix läuft und und und ...... *luft hol*

Also sagte ich zu ihm.. wie schauts mit FreeBSD aus? wenn ZFS dann knall FreeBSD drauf...
Sooooo jetzt basteln wir da paralel mal son bisschen herum... und ich habe herausgefunden das er neben normalen SATA Platten auch noch eine nvme Platte drin hat die zusammen in einem Mirror mit einer SATA 3 Platte geschaltet werden soll..

NVME ist für mich absolut neuland... ich hab noch nie mit den Dingern gearbeitet....
Gibts da irgendwas zu beachten?
Oder kann ich die Platten stumpf als Mirror zusammen klatschen und aus die maus?

Wie siehts dann Performance technisch aus? hat der gesamte Pool dann "nur" die Leistung von der SATA? oder wird das geteilt? oder weiß FreeBSD nvme ist schneller und führt dort bevorzugt seine Lese/schreib vorgänge durch, und spiegelt später die daten einfach nur auf die SATA herunter?

Oder geht das gar nicht?

Idee war jetzt bei seinem System:
250GB SATA SSD -> System + Applikationen
2x 2TB SSD (1x SATA 1x nvme) -> DataStorage
1x 4TB USB 3.1 HDD -> BackupStorage

Möglich? nicht möglich?
Sinnvoll? Sinnlos?
Bei 2x SATA platten wärs klar.. hab aber bedenken das der Raid später "lahmen" wird weil die SATA deutlich langsamer ist als die nvme....

Gruß
Sada
 
Hallo,

zu Deiner Frage kann ich wenig beitragen, mit meinem bescheidenen Basiswissen zu zfs.

Aber dass zfs unter Linux die von Dir geschilderten Schwierigkeiten haben soll, wundert mich.
Es gab erst kürzlich ein neues Feature in zfs, was wegen der konservativen Haltung unter FreeBSD noch nicht zu haben ist, unter Linux hingegen schon (schau mal unter pro-linux oder auch hier, da würde das diskutiert, weiß nicht mehr genau, worum es da ging, irgendwas mit Verschlüsselung).

Natürlich wäre es schön, mit Deinem Bekannten einen neuen FreeBSD-Nutzer zu bekommen, aber eine Entscheidung dafür sollte meines Erachtens nicht aufgrund einer Fehlannahme getroffen werden.
 
Moin moin @holgerw
holgerw schrieb:
Aber dass zfs unter Linux die von Dir geschilderten Schwierigkeiten haben soll, wundert mich.
Zum Vergrößern anklicken....
Im anhang dazu mal ein Screenshot aus dem offiziellen OpenZFS Wiki.
Nick vom Youtube Kanal unicks.eu hat das ganze grad auch in seinen Arch Tutorials erwähnt.
Außerdem hat der neue LinuxKernel schon wieder massig probleme mit ZFS...

Genau das ist ja auch der Grund, weswegen mein Bekannter von Linux unbedingt weg will (zu recht) ...
Mir geht das auch schon seit Jahren auf den Sack wie der Kernel von Torvalds entwickelt wird.... Alle 2 3 Tage ein neuer Kernel, und alle 2 3 Tage knallt es irgendwo.
Deswegen bin ich ja auch vor 3 Jahren angefangen von Linux weg zu gehen (auch wenn ich zwischendurch für speziellere sachen immer noch Ubuntu Studio benutze),
Ich brauche ein System wo ich den Schalter umlege und die Kiste läuft... Das wurd bei Linux ja immer schlimmer... Selbst die LTS Kernel von Distributoren wurden so schnell und Holprig entwickelt... das es selbst beim LTS Kernel bei mir (zum schluss) alle paar wochen zum totalausfall kam....

Egal... geht ja jetzt nicht um mich :D
Aber genau dieses Problem will mein Bekannter eben auch umgehen.... Er hat jetzt ein paar Monate mit Arch bzw Manjaro Linux herumgespielt... hatte alles auf BTRFS gehabt.. dann kam ein Update und das hat ihn mal eben das gesamte Dateisystem geschrottet.... Trotz Snapshots vom System (so das er hätte einen alten kernel booten können) war da nix mehr zu machen..... 100% Datenverlust... und das will er sich jetzt kein zweites mal mehr geben....
Verständlicher weise....
 

Anhänge

  • Auswahl_551.png
    Auswahl_551.png
    48,3 KB · Aufrufe: 400
Man darf mit ZFS on Linux halt nicht vergessen, dass es nicht Teil des offiziellen Kernels ist und aufgrund der heiligen GPL sehr wahrscheinlich auch nie werden wird. Nun braucht ZFS aber eine wesentlich höhere Integration in den Kernel als "normale" Dateisysteme, vor allem in die virtuelle Speicherverwaltung. Da können schon kleinere Änderungen an Kernel-Subsystemen zu größeren Problemen führen. Das Ganze ist daher eigentlich nur nutzbar, wenn man einen LTS-Kernel nutzt und idealerweise der Distributor noch die Anpassungsarbeiten übernimmt. Dazu kommt, das mag aber meine persönliche Macke sein, dass die ZFS on Linux Jungs recht schmerzfrei sind. Sie mergen gerne Mal Funktionen, die Illumos und FreeBSD für nicht stabil genug halten oder gehen auch mal mit dem Holzhammer (Stichwort: Merge des ganzen Illumos Crypto.Frameworks) vor.

Aber zur Frage. S-ATA oder besser als AHCI als Übertragungsprotokoll ist vom ganzen Aufbau her sehr auf klassische, rotierende Festplatten ausgelegt. Es hat zum Beispiel nur eine Command-Queue, in die das Betriebssystem die IO-Kommandos linear hineinlegt. Die einzige mögliche Optimierung ist, dass der Controller die einzelnen Kommandos umsortieren darf, es sei denn das Betriebssystem verlangt explizit eine Ausführung in der vorgegebenen Reigenfolge. NVMe hingegen ist im krassen Gegensatz dazu extrem auf die Bedürfnisse nicht rotierender, durchsatzstarker Flashspeicher optimiert. Es hat mehrere tausend Queues, die parallel gefüllt und abgearbeitet werden können. Dazu steckt da einiges an Hirnschmalz drin, um jeden noch so kleinen Flaschenhals effektiv zu vermeiden.

ZFS ist dumm. Es beachtete bei allen seinen Wegen Medien zu einem Pool zu verbinden die Eigenheiten der einzelnen Medien nicht und nutzt sie in etwa gleich. Damit bremst das langsamste Medium alle anderen aus. Legst du S-ATA- und NVMe-SSDs in einen Pool, wird die NVMe-SSD gebremst. Aber dein bekannter wird da kein Hochleistungsstorage brauchen und schon die theoretisch möglichen IOPS der S-ATA-SSDs aller Wahrscheinlichkeit nach nicht erreichen. Daher ist das völlig egal. :)
 
Yamagi schrieb:
Sie mergen gerne Mal Funktionen, die Illumos und FreeBSD für nicht stabil genug halten oder gehen auch mal mit dem Holzhammer (Stichwort: Merge des ganzen Illumos Crypto.Frameworks) vor.
Zum Vergrößern anklicken....
Man beachte dabei ... und FreeBSD für nicht stabil genug halten......
Genau das ist der springende Punkt weswegen ich vor etlichen Jahren schon mit meinen Servern auf FreeBSD gewechselt bin, und schlussendlich auch meinen Desktop auf FreeBSD umgestellt hab...
Ich komme mit unices sowieso besser klar als mit dem Windows gedöns... Und da ich mehr wert auf Stabilität als auf Gaming oder "schrottProgramme" lege ist mir die einschränkung von den 2 3 Programmen und 1 2 Hardwaregeräten relativ egal...

Mein Bekannter sieht das übrigens ähnlich.... Ihm wärs egal auf das eine oder andere Programm zu verzichten, solange sein PC grundlegend funktioniert...
Sound hatte anfangs Probleme gemacht (war aber dummer einstellungs fehler) aber ansonsten scheint jetzt Treibertechnisch bei ihm alles zu laufen.... ;)


Yamagi schrieb:
Aber dein bekannter wird da kein Hochleistungsstorage brauchen und schon die theoretisch möglichen IOPS der S-ATA-SSDs aller Wahrscheinlichkeit nach nicht erreichen. Daher ist das völlig egal.
Zum Vergrößern anklicken....
Gedacht hab ich mir sowas schon..... aber da wie gesagt nvme für mich selber neuland ist wollt ich lieber nochmal rückfragen :D
Das gleiche Problem wird er mit 1000000%iger Sicherheit auch unter BTRFS gehabt haben oder?
Letzt endlich muss er das entscheiden, aber ich geb das mal so weiter :D

Vielen Dank auf jedenfall...

Ahh mir fällt grad ein...
Theoretisch wärs ja auch erstmal den Pool so aufzubauen wie beschrieben.... und die SATA später mit einer zweiten nvme zu replacen... oder? ^^

Danke und Gruß
Sada
 
Sadakazu schrieb:
Theoretisch wärs ja auch erstmal den Pool so aufzubauen wie beschrieben.... und die SATA später mit einer zweiten nvme zu replacen... oder?
Zum Vergrößern anklicken....
Wovon du aber auch nicht so viel haben wirst, weil du den Pool für Daten benutzen willst.
Zumindest habe ich mal gelernt: das schnellste Medium sollte immer für das System genommen werden, weil hier die meisten Schreib- und Lesevorgänge laufen. Allerdings stimmt das ja bei manchen Konfigurationen gar nicht, so können die Schreib-Intensiven Teile ja auch ganz gut ausgelagert werden (eben auf die schnelleren Medien) und das "Rumpf-System" könnte sogar vollkommen read-only laufen (wie bei manchen embedded Lösungen). Nur erfordert so etwas schon einige Anpassungen, die man meistens nicht haben möchte.
 
Ich finde auf die Schnelle nichts und frage deshalb mal nach:
sind diese nvme-SSD Anschluss-Kompatibel zu SATA? Brauchen sie ein spezielles BIOS, muss ein MotherBoard als nvme-tauglich ausgewiesen sein? Oder kann ich einfach meine SATA durch nvme-SSD ersetzen und in den vollen Genuss der Vorteile kommen?
 
Persönlich sehe ich das ähnlich....
Wobei ich mir zum jetzigen Zeitpunkt noch keine nvme kaufen würde und schon gar nicht 2TB... das ist mir einfach zu viel geld für zu wenig nutzen....
Ich müsste auch mal bei mir neue Hardware verbauen...
Aber ich würd dann echt ne kleine (64GB oder so) SSD kaufen.. die fürs System nutzen und dann lieber 3x 3TB HDD Platten im raidz knallen.... und wenns mir ganz blöd in den kopf kommt auch 4x 3TB im raidz mit 1 spare.... was vielleicht auch noch sinn macht 3x 3TB HDD + 1x SSD Cache.... um nochmal bisschen die HDD platten zu boosten.... aber... für Dokumente Musik Bilder und Videos braucht man so einen "blödsinn" nicht...

Mirror ist Preis leistungstechnisch betrachtet einfach "zu teuer"
Zu deiner frage wegen anschlüsse...

Soweit ich weiß (aber nvme hab ich mich nie richtig mit befasst) ist ein neuer anschlussport... praktisch ein neuer Steckport.. die nvme SSD wird wie ein USB stick an diesem steckplatz angeschlossen und auf dem Mainbaord verschraubt.... Aber angaben ohne gewähr.... ich hab davon null plan... nur mal überflogen
 
Sadakazu schrieb:
Soweit ich weiß (aber nvme hab ich mich nie richtig mit befasst) ist ein neuer anschlussport... praktisch ein neuer Steckport.. die nvme SSD wird wie ein USB stick an diesem steckplatz angeschlossen und auf dem Mainbaord verschraubt.... Aber angaben ohne gewähr.... ich hab davon null plan... nur mal überflogen
Zum Vergrößern anklicken....

Statt Halbwahrheiten zu verbreiten, könnte man auch einfach auf der Wikipedia nachschlagen:
https://de.wikipedia.org/wiki/NVM_Express

Rob
 
Achja noch ein kleines ZFS problem grad...
Wir haben grad auf der 4TB (UBS) Platte ein zfs drauf geballert und wollten nun ein Backup seiner Linux grützdaten machen...
Bzw haben gemacht... dateisys war ein ext4... also fuse und alles ist hübsch...
Die daten stumpf mit cp -R von /mnt/linux/ nach /usbbackup/backupDataset rüberkopiert...

Vorhin dann die kiste neu gestartet.... gut... das ext4 wird nicht mit gemountet da nix in fstab eingetragen....
Aber..... warum zum geier wurde der pool usbbackup nicht automatisch beim neustart gemountet???

ein zpool status usbbackup zeigt das der pool online ist....
ein zfs list zeigt aber nicht an das es gemountet ist und ein
zfs get mounted usbbackup zeigt no....

Warum?
Bei internen Platten mountet er doch auch alle Pools automatisch durch.....
Verstehe ich grad irgendwie nicht....


KobRheTilla schrieb:
Statt Halbwahrheiten zu verbreiten, könnte man auch einfach auf der Wikipedia nachschlagen:
Zum Vergrößern anklicken....
deswegen hab ich explizit gesagt das ich keine ahnung davon habe ....
 
NVMe ist einfach ein Storage-System ähnlich wie S-ATA oder SAS. Was es schwer verständlich macht ist die Durchmischung der verschiedenen Standards. Heute hat man vor allem:

  • S-ATA: Nutzte ursprünglich die bekannten S-ATA-Ports mit den dazugehörigen Kabeln und / oder Backplanes. Bei S-ATA sind immer 3 Parteien beteiligt: Das Betriebssysstem, der Hostcontroller und das Speichermedium. Damit man nicht jedes Betriebssystem für jeden Hostcontroller einen Treiber schreiben muss, hat man sich mal auf AHCI als Protokoll für die Kommunikation zwischen Betriebssystem und Hostcontroller geeinigt. Als dann SSDs aufkamen, wollte man die auch per S-ATA ansprechen können. Im einfachen Fall wird die SSD auch einfach wie eine Festplatte angeschlossen. Aber man entwickelte außerdem mSATA als Slot für Steckkarten, was eine 1:1 Umsetung des oben beschrieben Prinzips ist. Außer kleinerer Baugröße gibt es keine Unterschiede und keine Vorteile. Später übernahm man den m.2-Slot von NVMe (siehe unten), rationalisierte den Host-Controller weg und programmierte den SSD so, dass er gegenüber dem Betriebssystem als normaler AHCI-Hostcontroller auftritt. Aus Sicht der Software ist es also ein normales S-ATA Storage, technisch aber nicht unbedingt. Das S-ATA Komitee fand das dann auch nicht so lustig und dachte sich S-ATA Express aus. Das ist im Prinzip die gleiche Lösung wie der beschriebene m.2-Weg, aber mit Ports statt Slots. Die Ports sind rückkompatibel zu normalen S-ATA. Auch wenn es viele Mainboards mit S-ATA Express Ports gab, setzte sich das nie durch und es gab kaum Medien.
  • SAS: Eine direkte Weiterentwicklung des alten SCSI. Nutzt S-ATA Ports, die meisten Controller sind dann auch zu S-ATA rückkompatibel. Wird gerade durch NVMe verdränmgt, ist aber in Servern noch weit verbreitet und wird sicher seine Nische für klassische Festplatten und spezielle Dinge wie Tapes behalten.
  • NVMe: Speziell für Flash-Speicher und verwandte Technologien entwickelt. Nutzt zur elektrischen Übertragung normales PCIe, kann daher direkt an die CPU andocken. PCIe ist sozusagen der physische Layer, NVMe der darauf aufbauende logische Layer. Da die Protokolle standardisiert sind, braucht man wie schon bei AHCI keine speziellen Treiber mehr, ein NVMe unterstütztendes Betriebssystem kann mit jeder NVMe Hardware kommunizieren. Am Anfang nutzte NVMe nur die normalen PCIe-Ports, später kam dann der m.2-Slot dazu und der u.2-Port. NVMe per m.2 setzt sich langsam durch, die meisten aktuellen Laptops und sehr viele (Fertig)-Desktops haben es. u.2 findet man nach wie vor fast ausschließlich in Servern.
FreeBSD kann NVMe seit 9.2, es kam ungefähr zeitgleich mit der Unterstützung durch Linux. Unter FreeBSD sind es normale CAM-Geräte, die als /dev/nvdX im System auftauchen. In 11.x funktioniert es gut, 12.0 wird noch eine Reihe Optimierungen mitbringen, die den Durchsatz drastisch steigern. Das ist aber nur für wirklich böse-große Storage-Systeme interessant, die außer Netflix kaum einer hat. ;)
 
Danke ausdrücklich mal wieder an Yamagi
ich sehe ja schon seit längerem immer mal wieder nach Mainboards, weil ich irgendwann mal erneuern muss (und so kurz vor Weihnachten...)
Lass mich mal beliebig aus einem Angebot zitieren:
Erweiterungsslots: 1x PCIe 3.0 x16, 1x PCIe 2.0 x16 (x4), 2x PCIe 2.0 x1, 2x PCI, 1x M.2/M-Key (PCIe 3.0 x4/SATA, 22110/2280/2260/2242)
Zum Vergrößern anklicken....
So oder ähnlich sieht das immer aus.
1x PCIe 3.0 x16 ist sicher für Grafik
1x PCIe 2.0 x16 vielleicht für eine schnellen Karte, evtl auch Grafik?
2x PCIe 2.0 x1 wäre dann eine Möglichkeit für NVMe mit PCIe Stecker ?
1x M.2/M-Key dann die andere Möglichkeit für NVMe ?
Und bedeutet das dann, dass ich bei solch einem MotherBoard also maximal drei NVMe-SSDs einbauen kann und davon aber nur zwei gleiche mit PCIe-Stecker?

Oder anders: wenn ich mehrere NVMe-SSDs nutzen will, darf ich nicht auf die Anzahl von SATA-Plätzen schauen, sondern brauche möglichst freie PCIe Slots oder mehrere M.2/M-Key?
 
Genau, du brauchst möglichst viele m.2 Slots oder Keys, wie sie in dem Beispiel heißen. Wobei die Anzahl schon dadurch begrenzt ist, dass sie PCIe-Lanes benötigen und die meisten Desktop-CPUs damit sehr knapp sind. Aktuelle Intel-CPUs haben nur 20 Stück, glaube ich. Davon gehen schon 16 für den PCIe-Slot für die Graka weg....
 
Yamagi schrieb:
Das ist aber nur für wirklich böse-große Storage-Systeme interessant, die außer Netflix kaum einer hat.
Zum Vergrößern anklicken....
xD
Mein bekannter hat jetzt seine pläne über board geschmissen und knallt FreeBSD auf die nvme als stripe...
die SATA wird nen einfaches backups storage.... und er hat nochmal 3x 4TB HDD nachgeordert die dann das backup vom backup werden das ganze dann im raidz...

Ich mein... Das nenn ich zwar Paranoid, jedenfalls für Privat... aber die Daten sind nicht nur Privat.. daher schon recht sinnvoll wenn er zusätzlich noch ein Raid Storage nutzt... wobei knapp 8TB Storage echt schon Massig viel ist xD

Yamagi schrieb:
Davon gehen schon 16 für den PCIe-Slot für die Graka weg....
Zum Vergrößern anklicken....
müsste man jetzt nur noch mal wissen wieviele Lanse ein nvme belegt...

ICH für meinen Teil werd meine kiste jetzt noch runternudeln bis sie echt komplett den geist aufgibt...
Und werd mich dann erst umgucken was dann Aktuell ist, und was mit FreeBSD machbar ist....

Fakt ist... mich bekommt man nicht mehr zurück zu Linux als Produktiv System :D
Zumindestens solange die Linux distris alle meinen ihren eigenen Brei kochen zu müssen und Torvalds die aktuellen Zyklen beibehält....
 
oha....
Bei "mindestens" 2 Lanes pro Device und 16 für die Grafikkarte und 20 Lanes hat ne Desktop CPU.... bleibt ja nix mehr für andere Geräte über oO
Ok.. ich glaub ich werd definitiv noch lange bei SATA bleiben :D
 
Der Mainboard-Chipsatz selbst stellt auch noch mal weitere PCIe Lanes zur Verfügung für USB, SATA, LAN, .... Man hat dann einen Link zwischen CPU und Chipsatz und kann dort weitere Sachen betreiben. Das alles teilt sich dann natürlich den Uplink zur CPU. Also 20 Lanes, 4 davon gehen fest zum Chipsatz, 16 davon zur Grafikkarte.

Die Anzahl der Lanes sind bei Intel ein weiterer Unterschied zwischen Consumer und Server-Hardware. Xeons haben wohl was an die 40 Lanes.
 
Genau, es bleibt nicht übrig. Der Ausweg sind dynamische Slots und PCIe-Switches. Bei dynamischen Slots bleibt dein schöner 16x Slot nur solange 16x, wie du nicht zu viele andere am PCIe hängende Slots belegst. Tust du das, werden einige Lanes umgeleitet und schon hast du nur noch einen 8x Slot. Bei PCIe-Switches wird eine Lane in mehrere Lanes gespalten, also also einer mach zwei oder so ähnlich. Das Problem dabei ist, dass die wenigen Lanes vor dem Switch dann zum Engpass werden.

Die meisten Mainboards der Intel Desktop-Plattform (Sockel 1151) verwenden eine Kombination aus beiden Techniken. Im Chipsatz steckt ein kleiner PCIe-Switch, der die Lanes der CPU (20 insgesamt - 4 für die Anbindung des Chipsatz = 16 direkt nutzbar) auf insgesamt 24 nutzbare Lanes erweitert. Außerdem ist der 16x PCIe-Slot meist mit den kleineren PCIe-Slots oder den m.2-Slots gekoppelt. Sie größeren Plattformen haben das Problem übrigens nichts. Sockel 2066 hat abhängig von der eingesetzten CPU bis zu 44 Lanes, AMDs Sockel AM4 immerhin 24 Lanes und für die Freunde des Overkills Sockel SP3 mit Threadripper 64 Lanes.

Viele Lanes sind zwar schön und sinnvoll, man muss aber auf der anderen Seite sehen, dass sie teure Pins an der CPU und Verbindungen auf der Platine brauchen. Bei den günstigen Plattformen rechnen sich übermäßig viele Lanes daher nicht. Vor allem, da ein absoluter Großteil der Hardware in Fertig-PCs ohne viel zusätzlicher Hardware landet.

EDIT: @-Nuke- war schneller :)
 
Man lastet zwar mit einer guten NVMe SSD den PCIe 3.0 x4 zwar vollkommen aus (und damit auch den CPU Uplink), aber man bewegt sich dann in Bereichen von 3-4GB/s. Hier muss man sich Fragen ob man das als Consumer wirklich braucht. Für den Consumer sind ja eigentlich IOPS der Geräte wichtiger als die Bandbreite. Hast ja auch nichts gewonnen, wenn du dein ganzes OS innerhalb von 2s in den RAM schieben könntest. Der Aufpreis zur Server-Hardware ist halt auch nicht ohne.

Aber das heißt natürlich auch, dass z.B. ein NVMe RAID0 auf einem Consumer-Board/CPU relativ sinnlos ist, außer die NVMe SSD schafft keine 3GB/s.
 
-Nuke- schrieb:
Aber das heißt natürlich auch, dass z.B. ein NVMe RAID0 auf einem Consumer-Board/CPU relativ sinnlos ist, außer die NVMe SSD schafft keine 3GB/s.
Zum Vergrößern anklicken....
Naja was heißt sinnlos...
Übertragen auf ZFS ist der einfache Stripe ja das klassische Raid 0....
Egal ob das jetzt ein "Raid" 0 aus einer Platte oder ein Raid 0 aus 10 Platten ist...
Wobei es keinen sinn machen würde (und da geb ich dir recht) wenn ich meinen Zpool mit nvme ssd + sata ssd ausstatte...

Die SATA platte wird also ihren eigenen Pool bekommen, sowie das Raid 3 vermutlich ebenfalls einen eigenen Pool bekommen wird (da diese über USB3.1 angeschlossen werden)

Somit werden das schon 3 Pools ;)
 
zfs stripe....
Nicht direkt Raid0

Sprechen wir mal in Devices und Polls

Pool -> Device(s)
============
zroot -> /dev/nvd0
backup -> /dev/ada0
Raid -> /dev/da0 /dev/da1 /dev/da2 spare /dev/da3
 
Sadakazu schrieb:
Raid -> /dev/da0 /dev/da1 /dev/da2 spare /dev/da3
Zum Vergrößern anklicken....
denk in ZRAID. Das ist viel gescheiter, als in klassischem Schema. Du hast eine Anzahl von Platten und verbindest die zu einem Pool und legst dabei den Grad der Redundanz fest. Du kannst natürlich mit nur zwei Platten keine zwei Platten Redundanz haben, aber nur mal so grundsätzlich gesprochen.
Lies dir die Dokumentation dazu mal durch.
 
Mir ist klar was du meinst...
Code: 
Type  | Poolname | Device
=======|==========|=====
Stripe | zroot  | /dev/nvd0
=======|==========|=====
Stripe | backup  | /dev/ada0
=======|==========|=====
Raidz1| Raid  | /dev/da0 /dev/da1 /dev/da2 spare /dev/da3
Mir ist durchaus bewusst das der backup Pool prinzipiell nicht viel sinn macht... denn:
das /usr/home/USER/geheimeDaten (ein beispiel) wird als backup auf den backup pool geschickt
Von dort aus nochmal auf den Raid Pool um ein redundantes backup, der Backupdaten zu haben....

Klingt Paranoid und "sinnfrei" aber er will es halt so haben ^^

ICH hätt das ganze recht Schmerzfrei in 2 Pools aufgeteilt:
Code: 
Type  | Poolname | Device
=======|==========|=====
mirror | zroot  | /dev/nvd0 /dev/ada0
=======|==========|=====
Raidz1| backup  | /dev/da0 /dev/da1 /dev/da2 spare /dev/da3
Vom backup Pool lieber nochmal auf einen NAS replizieren.... wenn man es unbedingt paranoid braucht....
Aber wie gesagt... er wills so haben.....

Davon Abgesehen würd ich den Raidz1 sowieso lieber als HDD intern haben wollen anstelle von USB Platten.... auch wenn USB 3.1 schon recht fix ist..... das Kabelgewirr geht mir so ja schon auf die Nüsse....
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben