[Sammelthread] ZFS Stammtisch

[gea]

Das kann sich doch sehen lassen, sind excellente Ergebnisse (Ist das Slog eine Intel Optane?)

655 MB/s async Schreiben ist ganz nett und reicht für 10G, aber damit 388 MB/s sync Rate zu machen ist hammermäßig. Auch die Random Write Werte sind erstklassig (sync aund async). Beim Lesen geht der Lesecache stark mit ins Ergebnis rein.

 

[Fischje]

Na dann bin ich ja sehr zufrieden. Ja ist die von dir empfohlene Optane mit 58 GB. Die sprengt ja nicht mein Budget.

Jetzt überlege ich noch wie ich den Storage am besten (schnellsten) intern an den ESXI anbinde. NFS hatte ich jetzt zunächst gedacht, dann könnte ich aber nicht pro vm ein dataset kreieren, richtig? ich hab irgendwo in den napp-it manuels gelesen, mann solle doch pro vm (oder war es server) ein dataset nutzen oder ist das unsinn?

die erste vm soll ein filer sein, die anderen vms sind cache-server oder mal ein gameserver oder halt was zur hausautomation und dann ein projekt wo ich mal ein paar dms ausprobieren wollte. die beiden 1 TB platten tausche ich demnächst gegen schnellere, neuen 6 TB platten.

 

[gea]

Man könnte natürlich pro VM ein Dateisystem anlegen und das per NFS freigeben. Ist aber nicht sonderlich praktisch. Ich würde einfach ein Dateisystem mit NFS3 für VMs (das sind dann einfache Ordner auf dem Dateisystem) anlegen und darauf alle VMs ablegen. Das Dateisystem dann auch für SMB freigeben damit man einfachen Zugriff auf die VMs für move/clone/backup hat und per Windows Previous Version auch einzelne VMs aus einem ZFS Snap wiederherstellen kann.

Ein Dateisystem per VM macht man nur bei iSCSI damit man die einzeln aus Snaps wiederherstellen kann. Für den Filer einfach ein weiteres Dateisystem per SMB freigeben.

Optane war eigentlich klar. Selbst mit einer Intel DC 3700 als Slog (früher mal das Beste) wären kaum mehr als 50MB/s sequentiell mit sync drin gewesen.

 

[JohnnyBGoode]

Ein ZIL (onpool) oder Slog (separate SSD/NVMe) ist zunächst kein Schreibcache (Schreibcache bei ZFS ist im RAM, default 10% RAM/ max 4GB) sondern die Absicherung des Schreibcaches damit der Inhalt beim Crash nicht verloren geht. Gelesen wird der nur nach einem Crash beim Booten. Von der Funktion ist das also wie die Batteriepufferung bei einem Hardware-Raid, nur besser/ schneller.

Die kleinen Optane bringen nicht so viel und machen auch Probleme unter ESXi. Ich würde unter der 800P-58 GB nicht anfangen. Die ist dann so schnell wir eine teure Enterprise Optane 4800X

Ein L2Arc ergänzt den schnellen Ram-Lesecache Arc um "langsamen" SSD Speicher. Zum Verwalten der SSD muss man etwa 5% der Kapazität im RAM rechnen. Ein L2Arc sollta daher niemals mehr als 10x RAM groß sein, 5x RAM ist ein guter Wert. Mehr RAM ist aber immer schneller als ein L2Arc.

Partitionen in napp-it
Im Menü Disks kann man den Support für Partitionen aktivieren und die Platte partitionieren.
Da ESXi noch Probleme mit Optane und pass-through macht, ist der Weg aber eher so dass man eine virtuelle Platte in ESX auf der Optane anlegt (Slog ca 20GB, L2Arc dann 5x RAM) und die in den Pool einbindet.

Kann man eigentlich auch "richtigen" Schreibcache mit NVMe-Laufwerken nachrüsten? Wenn man beispielsweise bereits unterschiedliche Kombinationen an Laufwerken hat (2 x SATA-SSD als Mirror, ein paar größere RAIDZ2s mit mechanischen HDDs), kann man eine Optane mit 480 GB hinzufügen, die die Schreibvorgänge aller anderen Laufwerke "abfedert", gerade bei 10+ GbE sind die 4 GB RAM Schreibcache ja recht schnell futsch (gehe von einem Szenario aus, bei dem die Netzwerkverbindungen Client-/Server-seitig tatsächlich dauerhaft ausgelastet werden können und insbesondere mehrfacher Zugriff auf die mechanischen Platten zu Engpässen führt).

 

[gea]

Eine SSD/NVMe als Schreibcache würde was bringen wenn man dahinter einen viel langsameren Speicher z.B. eine langsame Platte hat - aber nur für kurze intervallartige Schreibvorgänge. Dazwischen muss der Cache geleert werden. Sonst läuft er voll. Sonst hat man Schreibvorgänge vom Cache, vom Client und den ganzen Verwaltungsoverhead: es wird nur noch langsamer. Eigentlich gibt es dafür nur den Anwendungsfall Mediaserver (meist lesen, selten schreiben, single Disk Betrieb)

Dazu darf der Cache die Datensicherheit nicht gefärden. Man muss dem Schreibcache also mindest die Redundanz/Raidsicherheit des Pools geben und sich Gedanken um Powerloss Protection machen.

Ein typischer ZFS Pool besteht aber aus mehreren Platten. Bei denen addiert sich die sequentielle Schreibleistung bei Raid-z aus der Anzahl der Datenplatten bzw bei Mirror aus der Anzahl der vdev. Ein 8 Platten Raid-z2 hat daher z.B. eine sequentielle Schreibperformance von 6 x Einzelplatten. Aktuelle Platten haben eine sequentielle Performance von sagen wir mal 200 MB/s, allein ein derartiges vdev kommt damit auf bis zu 1200 MB/s. Das reicht schon aus um 2 x 10G auszulasten und ist besser als viele NVMe und 3 x so schnell wie die schnellste SSD. Professionelles ZFS Storage hat gerne mal mehrere solche vdevs. Die Poolperformance ist die Summe aller vdevs.

ZFS nutzt daher viel schnelleren RAM für den Schreibcache. Die Frage ist jetzt wie groß muss der sein. Man könnte den ja auch größer einstellen. Sequentiell bringt das aber nichts, da der Pool selber bereits schneller als jedes Netz ist.

Der Augenmerk des ZFS Schreibcaches liegt daher auf einem anderen Aspekt.
Die kleinste Datenmenge die geschrieben werden kann ist 4k (phyical Blocksize). Eine Platte hat ca 100 iops (Kopf positionieren, Sektor abwarten). Im worst case könnte man als 100 x 4k wahlfrei schreiben als ca 400KB pro Sekunde. Sowas gilt es unter allen Umständen zu vermeiden. Der ultraschnelle RAMcache sammelt daher alle Schreibvorgänge mit dem Ziel, daraus einen großen sequentiellen schnellen Schreibvorgang zu machen (wir erinnern uns: 1200 MB/s). Die Größe des ZFS Schreibcaches ist darauf optimiert selbst mit kleinen Schreibaktionen volle Performance zu erreichen.

Das Problem kommt erst wenn der Inhalt des Schreibcaches crashsicher sein muss. Aber dafür hat Sun in ZFS ja das Slog Konzept entwickelt und dafür macht eine Optane dann Sinn. Ein Slog muss aber nie größer als ca 20 GB sein, selbst nicht bei Solaris und 40G Netzwerken.

RAM ist damit nicht nur "richtiger" Schreibcache sondern besserer Schreibcache,

 

[MisterY]

Ich spiele mit dem Gedanken alles in meinem Fileserver zu konzentrieren. Da sollen aus 6 3TB Hdds ein striped mirror (3*2 HDDs) entstehen, aus 2*8TB ein weiterer mirror. Und dann ein striped vdev aus 6+ SSDs. Weiterhin noch 6*1TB in striped mirrors.

Auf die 3TB Platten sollen Programme, Backups und Arbeitsdateien. Auf die 8TB Mediendateien. Die SSDs sollen als schneller Speicher für Videoschnitt fungieren (die Dateien werden nach Fertigstellung auf die 3TBs verschoben). Die 1TBs stellen Speicher für meine Proxmox Server dar.

Aktuell ist mein Fileserver ein A10 6800k mit 16 GB non-ECC und einer mellanox connect-x2 und einer h310. Ich denke, dass ich auf ECC setzen sollte, oder was meint ihr?

Würde ein Pentium G mit 4 Threads reichen? Ich denke, dass ich auch von OMV zu Nas4free wechseln werde, da Linux Kernel >4.9 die mellanox nicht mehr unterstützt.

Wie sieht es bei Bsd aus?
Ich würde an der H310 gerne einen Expander anbringen. Wie sieht es da mit den Transferraten aus?
Macht das Sinn, alles zu konzentrieren?
Ich möchte Datendoppel vermeiden. Backups finden auf einen zweiten Server mit mergerfs statt

 

[CommanderBond]

Hallo, ich benutze zur Zeit 2 Samsung 830 SSDs als Mirror als Datenpool. Habe vor bald auf mindestens 1TB SSDs umzusteigen, bin mir jetzt aber unsicher ob ich Features wie PLP brauche.
Aktuell sind eigene Daten drauf und 2 VMs.
PLP SSDs kosten ja einiges mehr, das Geld würd ich mir eher sparen bzw stattdessen dann eher eine SSD mit mehr Kapazität nehmen. Weiß jemand wie kritisch das ist? Bei den meisten Diskussionen hier ging es meine ich um SSDs als Cache, ich will sie als Pool benutzen.
Hatte aktuell an eine Samsung 860 EVO gedacht.

Kann ich mit einem 2 SATA3 SSDs als Mirror ein 10Gbit Interface ausreizen? Also liest ZFS von beiden SSDs gleichzeitig und käme damit theoretisch auf irgendwas um die 1000-1100MB/s lesend?

Wenn der SATA Controller schnell genug angebunden ist, kann er dann theoretisch an jedem Port die volle Bandbreite gleichzeitig bereitstellen oder gibt es da noch weitere Limitierungen?

 

[gea]

ZFS liest von beiden Mirrors gleichzeitig. Lesen ist also ok. Bei Schreiben gibt es aber folgende Probleme

- Bei Desktop SSDs bricht die Schreibrate bei constantem Schreiben nach einiger Zeit heftig ein
Wenn man also sync aktiviert kann das recht lahm werden

- Deskop SSDs haben meist einen nternen DRAM Cache. Die letzten Schreibvorgänge auch bei sync oder das interne Garbage Collection mögen keinen Crash beim Schreiben (korrupte Daten).

Man könnte den SSDs allenfalls eine Optane als Slog zur Seite stellen. Damit ist das Thema Powerloss Protection unkritischer und die Schreibperformance bricht mit Sync nicht so ein.

 

[Trambahner]

Ein bissl kann man manchen Desktop-SSDs "helfen", in dem man das Overprovisioning erhöht (sprich z.B. Partitionen kleiner anlegt) und so dem Controller mehr Raum zum Arbeiten gibt.

@CommanderBond: 1TB ? Schau Dir mal die SM863 960GB an. Gibts im Abverkauf derzeit relativ günstig, da die Nachfolgerin (SM883) da ist. SM863 = 850pro mit Enterprise-Features fürs Datacenter. Nachteil: keine Hersteller-Garantie; nur die gesetzl. Gewährleistung vom Händler für Privatkunden.
Vorteil: Performance bei leichter desktopähnlicher Belastung wenige Prozent unterhalb der der 850pro (also recht hoch) und trotzdem hohe garantierte Mindest-IOPS bei Dauerlast. Diese Worst Case IOPS kannst weiter anheben, in dem Du da auch noch mehr Overprovisioning einstellst (das Ding hat eh schon mehr als eine Desktop 850pro).

Ich hab netto etwa 850 GiB (oder warens 820? weiß nicht mehr auswendig) pro SSD partitioniert und mir aus 6 solchen SSDs dann einen ZPool aus 3 Mirror-Vdevs gebaut.

Schaut mit Bonnie++ dann ohne Compress so aus (SSDs hängen an SAS3008-Controller, nicht an Sata-Ports):
Ich kann leider nicht mit Napp-It Benches dienen, da das unter BSD bei mir läuft.

[FONT=Courier New]Version  1.97       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
servername    24G   290  99 1193624  90 745090  80   854  99 1910795  92 12134  81
Latency             30325us    3520us   28326us   11568us    1098us    9150us
Version  1.97       ------Sequential Create------ --------Random Create--------
servername        -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++
Latency              1276us      60us     156us    1246us      20us      46us
1.97,1.97,servername,1,1531426925,24G,,290,99,1193624,90,745090,80,854,99,1910795,92,12134,81,16,,,,,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,30325us,3520us,28326us,11568us,1098us,9150us,1276us,60us,156us,1246us,20us,46us
[/FONT]

Man kann hier z.B. beim sequentiellen Durchsatz wunderbar sehen, wie beim Lesen deutlich mehr als beim Schreiben geht.

 

[CommanderBond]

Also Performance ist mir nicht ganz so wichtig, bzw genauer gesagt ob die bei 100GB am Stück gehalten werden kann beim Schreiben, sowas habe ich daheim halt nicht. Es gibt ja auch noch PLP nur für ruhende Daten, was ist von diesen zu halten?
Ich mach zwar auch Backups, aber wenn ich Angst haben muss bei nem Stromausfall wegen den Daten, habe ich vom Umstieg HDD auf SSD letztendlich auch nicht viel gewonnen.

Garantie wäre mir egal, wenn kaputt dann muss man eben neue kaufen, die Daten sind eh wichtiger, Hardware kann man zur Not auf eigene Kosten ersetzen.

 

[Trambahner]

SM863 hat PLP (im Gegensatz zur 850pro). Btw, es gibt auch die TLC-Varianten davon (PM863 dann (hat auch PLP) , die SM863 ist MLC), die sind dann eher für leseorientierte Anwendungen

Diese Generation hat zwar bereits Nachfolger, aber die hat i.W. halt höhere Speicherdichte pro Baustein, einen etwas schnelleren Controller und wohl etwas kürzere Latenzen.
Für daheim sollte das Jacke wie Hose sein, da die SM/PM863 schon ordentliche Datacenter-SSDs sind. Insbesondere für die aktuellen Preise bei den 960er Modellen.
Review
Ich bin ernsthaft am überlegen, noch ein 4. Päärchen zu holen.

 

[CommanderBond]

Hab jetzt ne PM863a gefunden für 288euro mit 960GB. Was ist der Unterschied zu dem Modell ohne a ?
Allerdings bekommt man ne SanDisk Ultra 3D (natürlich ohne PLP) grad für 300euro mit 2TB. Sprich pro GB der halbe Preis.

 

[Trambahner]

Die "a"-Modelle sind Refreshs mit Flashchips eine Generation jünger (=höhere Speicherdichte pro Baustein).

 

[CommanderBond]

Ok thx

Es gibt ja auch noch die Sandisk SSD Plus and Z410, beide wohl ohne DRAM, und entsprechend "schlechter" Performance. Könnte das aber nicht sogar ein Vorteil sein bei Platten ohne PLP, wenn es keinen DRAM gibt?
Wie ist eure Meinung, taugen die als reine Datenplatten etwas (für Homeuse), wenn man keine VMs drauf packt sondern wirklich nur Dokumente, Bilder, Musik etc ? "DRAM" hat man doch quasi über ZFS ohnehin schon.

 

[gea]

Ich sehe das wie beim Auto.
Entweder man ignoriert Risiken die nur mit ABS und ESP verringert werden können oder man kauft ein Auto mit diesen Features.

Enweder man ignoriert das Rest-Risko eines Datenverlusts im Falle eiens Crashes bei Schreiben oder man braucht SSD/NVMe mit garantierter PowerLoss Protection und das heißt fast automatisch die Datacenter Linie von Samsung oder Intel.

Die einzige halbwegs sichere Flashplatte ohne garantierte PowerLoss Protection ist eine Intel Optane unterhalb der 4800x. Die sind tatsächlich so aufgebaut dass das Risiko gering ist (kein Dram, kein Trim, kein Löschen vor dem Schreiben, keine Garbage Collection, schnell, Intel garantiert PLP aber dennoch nur bei Optane 4800x)

 

[CommanderBond]

Kann man ja so sehen. Frage mich nur ob es technisch gesehen eben auch ein Vorteil darstellen kann kein DRAM zu haben wenn man den Aufpreis für PLP nicht zahlen will. Sprich ob das Risiko für Datenverlust einer nonPLP SSD mit und ohne DRAM gleich hoch ist. Für mein Verständnis kann halt das was im DRAM ist nicht verloren gehen wenn es keinen DRAM gibt. Das dies nur ein Faktor von vielen ist ist klar

 

[Trambahner]

Der DRAM-Cache auf klassischen Flash-SSDs ist ja oft auch wesentlich für den Controller für die Pagetables-Verwaltung; es ist der Arbeitsspeicher des Controllers. Für Userdaten steht ja nur ein Anteil zur Verfügung. Ohne DRAM bleibt dem Controller nur sein Registersatz bzw. ggf. minimaler internes Ram.
Sprich, das Ding muss ständig seine Verwaltungsdaten hin- und herschaufeln. Der Performance-Hit kann dabei so massiv werden, dass solche SSDs selbst unter einfacher Windows-Installation das stottern anfangen können, wenn sie gut belegt. Da möcht ich keine VMs drauf haben. Und wenn ZFS da "draufdonnert", vielleicht noch mit Sync-Writes => ohoh.... tu Dir das doch nicht an.

Da Du nicht weisst, wie der Dram-less Controller mit seinen aktuellen Registerinhalten oder kleinem embedded Ram umgeht wenns den Strom wegzieht, ist so eine Dram-less SSD keine sichere Wette.

 

[CommanderBond]

Okay, dann gibts ja noch Powerloss Immunity, so nennt Crucial PLP für ruhende Daten. Im Grunde hätte man hier doch schon die gleiche Sicherheit in dem Fall wie mit HDDs, weil den Cache schreiben HDDs soweit ich weiß bei einem Stromausfall auch nicht mehr auf die Magnetscheiben.

 

[jonofe]

Ich bin gerade dabei den Inhalt meines OMV NAS auf meinen napp-it Server umzuziehen.
Ich habe dazu die OMV Daten auf eine externe USB Platte mit ext4 Filesystem gesichert.
Dann habe ich die OMV Platten in napp-it eingebunden, initialisiert und einen neuen Pool mit entsprechenden Filesystemen angelegt.

Wie bekomme ich die Daten von der USB Platte nun am schnellsten auf den napp-it Pool?

Kann ich in meiner napp-it VM (OmniOS/ESXi) ext4 Filesysteme von einer USB Platte mounten und den Kopiervorgang lokal machen?

Alternativ habe ich bereits mal begonnen, auf einer anderen Linux VM per USB Mount und NFS die Daten rüberzuschaufeln. Das dauert allerdings ziemlich lange.

Andere Ideen?

 

[gea]

Solarish unterstützt ext4 nicht out of the box (Solarish ist mehr oder weniger ZFS only).
Das einfachste ist es tatsächlich die Daten übers Netz (ESXi intern per vmxnet3) per SMB oder NFS zu kopieren.

 

[kandamir]

Mal eine kurze Frage zum Thema Backup / ZFS Clone erstellen:

Ich habe vor einiger Zeit mein NAS auf einen napp-it Server umgezogen. Die Migration der Daten lief über ein ziemlich krudes Konstrukt, da ich mit den verfügbaren Platten auskommen wollte/musste und ich immer ein aktuelles Backup haben wollte, das beim nächsten Migrationsschritt nicht involviert war. Das ist soweit auch gelungen. Situation ist jetzt folgende:

ZFS-Pool Data1 => produktiv in Nutzung, 1x 2TB, davon 1.24 TB belegt.
ZFS-Pool Migration => 1.3TB Kapazität, bestehend aus Mix von 2x 500GB HDDs und ESXI virtual Disk basierend aus SSD. War der Container, mit dem die Daten zuerst auf napp-it gewandert sind. Idlet jetzt vor sich hin, nicht mehr ganz aktuell.

Der Pool Migration wurde also nach Data1 geklont. Preisfrage: Kann ich den Migration Pool jetzt temporär als Backup Ziel verwenden? Sprich die Richtung umdrehen, indem ich beim zfs clone den Migration Pool als Ziel angebe? Wird der dortige Datenbestand als Ausgangspunkt für ein Delta gebildet oder wird zfs clone den Migration Pool komplett neu befüllen wollen? Ich will den Migration Pool nur einmal als Backup Ziel verwenden und dann offline stellen, um dann mit der derzeitigen Backup Platte einen Backup ZFS Pool zu erstellen. Das soll dann bis auf weiteres das regelmäßige Backup-Ziel werden.

Danke für Eure Hinweise!

 

[gea]

Bei der Replikation hat man auf beiden Seiten das Dateisystem mit einem geneinsamen Basissnap für die folgende Replikation. Man kann darauf aufbauend problemlos die Richtung umkehren.

Dazu auf dem neuen Zielsystem einen Replikationsjob für das vorhandene Dateisystem anlegen und dazu die JobID des vorhandenen Jobs (ersichtlich aus den Snapnamen) verwenden.

Man kann jedoch nicht mit Clones (beschreibbares Dateisystem das aus einem Snap erzeugt wurde) arbeiten sondern nur mit einem Dateisystem selber und den darauf angelegten Snaps.

Einen Clone müsste man komplett replizieren.

 

[CommanderBond]

Mal ne Frage zu der Option "copies". Wenn ich ne einzelne USB Backup HDD benutze und Copies=2 setze, hat die Option irgendwelche weitere Einschränkungen? In Bezug auf Replications oder Snapshots. Oder müssen beide ZFS-Ordner gleich konfiguriert sein. Bzw wie bekomme ich es hin dass ein Dataset auf einem Mirror mit copies=1, auf meinem Backup Medium aber copies=2 benutzt. Muss nicht immer alle identisch sein bei Replicationen? Und was passiert wenn an die Eigenschaft nachträglich aktiviert, werden die Daten dann erstmal kopiert oder betrifft es nur neu hinzugekommene Daten?

 

[Bzzz]

Was erhoffst du dir denn von der zweiten Kopie auf einem einzelnen Datenträger?

 

[besterino]

Keinen Datenverlust bei defekten Sektoren zum Beispiel.

 

[gea]

Eine Replikation überträgt ein Dateisystem, es werden aber nicht alle Dateisystem-Eigenschaften übertragen. Manche Eigenschaften werden auf dem Ziel-Dateisystem gesetzt oder beibehalten, teilweise durch Setzen der Werte auf Pool-Ebene und Vererbung der Eigenschaft auf anschließend darunter angelegte Dateisysteme.

Copies, Compress oder Dedup gehören dazu. Man kann Copies=2 also auf dem USB Pool selber per zfs set copies=2 poolname aktivieren und eine anschließende Replikation mit dem USB Pool als Ziel wird alle Daten doppelt schreiben.

Die Kapazität der USB Platte halbiert sich dann allerdings. Die Alternative wären zwei USB (oder entfernbare Sata) Platten aus denen man einen Mirror baut. Das würde einen kompletten Plattenausfall und nicht nur einen defekten Sektor aushalten.

 

[wit4r7]

Hallo,

als ZFS Neuling stehe ich gerade vor einem - für mich - unlösbaren Problem. Ich nutze ein Proxmox auf 2 SSDs im Mirror sowie 2 HDDs ebenfalls als Mirror. Auf den 2 HDDs liegen 3 LXC Container, welche etwas Probleme verursachen. Und zwar wird der Pool bzw. die Subdisk nicht automatisch gemounted.
Ein manuelles "zfs mount -a" löst das Problem und ich kann die Container manuell starten.

Hier noch ein Log, welcher auch zeigt, dass mein "vm-storage" nicht automatisch gemounted wird.

root@pve:~# journalctl -b -u "zfs*" -u "local-fs.target" -u "pve-manager"
-- Logs begin at Thu 2018-10-18 10:26:45 CEST, end at Thu 2018-10-18 10:29:52 CEST. --
Oct 18 10:26:46 pve systemd[1]: Starting Import ZFS pools by cache file...
Oct 18 10:26:48 pve zpool[2585]: cannot import 'vm-storage': no such pool or dataset
Oct 18 10:26:48 pve zpool[2585]: Destroy and re-create the pool from
Oct 18 10:26:48 pve zpool[2585]: a backup source.
Oct 18 10:26:48 pve systemd[1]: zfs-import-cache.service: Main process exited, code=exited, status=1/FAILURE
Oct 18 10:26:48 pve systemd[1]: Failed to start Import ZFS pools by cache file.
Oct 18 10:26:48 pve systemd[1]: zfs-import-cache.service: Unit entered failed state.
Oct 18 10:26:48 pve systemd[1]: zfs-import-cache.service: Failed with result 'exit-code'.
Oct 18 10:26:48 pve systemd[1]: Reached target ZFS pool import target.
Oct 18 10:26:48 pve systemd[1]: Starting Mount ZFS filesystems...
Oct 18 10:26:48 pve systemd[1]: Started Mount ZFS filesystems.
Oct 18 10:26:48 pve systemd[1]: Reached target Local File Systems.
Oct 18 10:26:49 pve systemd[1]: Starting ZFS file system shares...
Oct 18 10:26:49 pve systemd[1]: Started ZFS file system shares.
Oct 18 10:26:49 pve systemd[1]: Reached target ZFS startup target.

Weiß einer, wo der Fehler liegt und kann mir helfen?

Vielen Dank!

 

[CommanderBond]

Eine Replikation überträgt ein Dateisystem, es werden aber nicht alle Dateisystem-Eigenschaften übertragen. Manche Eigenschaften werden auf dem Ziel-Dateisystem gesetzt oder beibehalten, teilweise durch Setzen der Werte auf Pool-Ebene und Vererbung der Eigenschaft auf anschließend darunter angelegte Dateisysteme.

Copies, Compress oder Dedup gehören dazu. Man kann Copies=2 also auf dem USB Pool selber per zfs set copies=2 poolname aktivieren und eine anschließende Replikation mit dem USB Pool als Ziel wird alle Daten doppelt schreiben.

Die Kapazität der USB Platte halbiert sich dann allerdings. Die Alternative wären zwei USB (oder entfernbare Sata) Platten aus denen man einen Mirror baut. Das würde einen kompletten Plattenausfall und nicht nur einen defekten Sektor aushalten.

Eine tolles Feature wäre doch eigentlich wenn man statt copies einfach ein Redundanzlevel angeben könnte wieviel Prozent des Plattenplatzes für Redundanz benutzt werden, würde nicht soviel Speicherplatz dann benötigen

 

[Bzzz]

Und wie soll das System auswürfeln, welche Dateien da nun rein dürfen und welche halt Pech gehabt haben? Oder soll jede Datei anteilig rein, damit auch ja genau der fehlende Block nur einmal vorhanden ist und die Prüfsumme auch noch im kaputten zweiten Block liegt? Zaubern kann ZFS halt dann doch noch nicht...

 

[CommanderBond]

Kannst doch einfach Parität bilden über mehrere Blöcke. Nimmst 10 Blöcke, errechnest daraus einen Paritätsblock. Selbes Prinzip wie bei Winrar, dort kannst du das auch machen, zB bei mehrteiligen Archiven, die Widerherstellungsteilarchive haben die Endung .rev meine ich. Und mit jeder Datei kannst du eine fehlende wiederherstellen bzw reparieren.
100% bekommste sowieso nicht, aber das geht auch mit copies nicht, es kann ja sein das 2 defekte Sektoren genau zufälligerweise einmal das Original und einmal die Kopie zerstört haben.

Mit den Prüfsummen hats ja nix zu tun, die speichert soweit ich weiß ZFS sowieso mindestens 2mal ab. Im Grunde würde hier ja nur jeder x. Block eben keine Userdaten sondern Parität der Userdaten enthalten.

napp-it // webbased ZFS NAS/SAN appliance for OmniOS, OpenIndiana, Solaris and Linux : Extensions

Mit den Blockdevices würde es sogar gehen so wie ich das verstehe, nur wäre es dann nicht Blockbasiert sondern filebasiert.

Advantage
It is very elegant, easy to implement and simply based on one or more encrypted files.
If you want to backup them, you can just copy them. With small files its not a problem, even on FAT disks
with a max file limit of 2 GB. If you have build redundant ZFS pools from several files (ex Raid-Z2) its even not
a problem if two files get damaged for whatever reason on your backup disk. (encrypted backup with full ZFS data security)

Im Grunde wirds ja hier beschrieben, wenn man sich die encryption weg denkt.

Mit Raid-Z3 könnten dann bis zu 3 meiner Dateien beschädigt sein, weil der Sektor der HDD auf dem sie gespeichert wurden fehlerhaft ist.
Und über die Anzahl und Größe könnte ich steuern wieviel % Plattenplatz ich dafür benutze.

Aber dass ich bei copies=2 50% Platz verliere ist nicht so schlimm, weil ich eh nur 1-2TB sichern möchte und der "Sweetpoint" bei HDDs sowieso bei größeren Kapazitäten liegt. Sprich obwohl man 50% verliert, muss man nicht das doppelte ausgeben, weil ne 4TB Platte nicht das doppelte einer 2TB Platte kostet. Fürs Backup käm für mich eh nur ne 2,5 USB HDD in Frage. Sprich sparen tue ich kaum, weil bei kleineren HDDs ich einen höheren Preis/TB zahlen müsste. Von daher trotz 50% Verlust noch attraktiv. Bei nem Mirror hätte man so oder so die doppelten kosten egal welche Kapazität