Das längste Thema

  • Ich werfe mal wieder ZFS in den Thread 8)


    Ich möchte einen meiner (rein privat genutzten) ZFS-Pools unter TrueNAS (CORE) von Mirror (2 HDDs) auf RAID-Z1 (3 HDDs) migrieren. Die Nachteile und Risiken von RAID-Z1 sind mir bewusst. Ich teste das derzeit mit einem kleineren Testpool intensiv aus und bemerke erneut, dass ich damals wahrscheinlich einige Fehlentscheidungen getroffen habe. Zum Beispiel ist der gesamte Pool verschlüsselt und somit auch das Root-Dataset, was in vielen Situationen absolut nicht ideal ist. Es macht aber auch keinen Sinn, wenn ich jetzt zig Datasets einzeln verschlüsseln und somit auch entsperren müsste, weil die Einstellung nicht mehr vererbt werden kann. Sehe ich das richtig, dass eine Art Pseudo-Root-Dataset sinnvoll(er) wäre?


    Ist-Zustand:

    • mypool (verschlüsselt)
    • mypool/dataset1 (verschlüsselt)
    • mypool/dataset2 (verschlüsselt)
    • mypool/dataset2/childA (verschlüsselt)


    Geplanter neuer Zustand:

    • mypool-new (unverschlüsselt)
    • mypool-new/encryptedroot (verschlüsselt)
    • mypool-new/encryptedroot/dataset1 (verschlüsselt)
    • mypool-new/encryptedroot/dataset2 (verschlüsselt)
    • mypool-new/encryptedroot/dataset2/childA (verschlüsselt)
    • mypool-new/foobar (unverschlüsselt)


    Ich könnte also eigentlich 1:1 das alte Root-Dataset als RAW-Stream zum neuen Pool senden und würde alle alten Snapshots behalten können? :/

    Code
    zfs snapshot -r mypool@snapshot
    zfs send -Rw mypool@snapshot | zfs recv -Fusv mypool-new/encryptedroot


    Danach die beiden Pools exportieren und beim Import die Namen anpassen:

    • mypool » mypool-old
    • mypool-new » mypool


    Zuletzt noch die Pfade überall anpassen. (Bisher wird sowieso hauptsächlich über SMB auf TrueNAS zugegriffen, die geänderten Pfade z.B. für NFS sind zu vernachlässigen.)


    Anregungen? (/cc m_ueberall ^^)

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    3 Mal editiert, zuletzt von KB19 ()

  • Zum Beispiel ist der gesamte Pool verschlüsselt und somit auch das Root-Dataset, was in vielen Situationen absolut nicht ideal ist. Es macht aber auch keinen Sinn, wenn ich jetzt zig Datasets einzeln verschlüsseln und somit auch entsperren müsste, weil die Einstellung nicht mehr vererbt werden kann. […]

    Ich könnte also eigentlich 1:1 das alte Root-Dataset als RAW-Stream zum neuen Pool senden und würde alle alten Snapshots behalten können? :/

    Code
    zfs snapshot -r mypool@snapshot
    zfs send -Rw mypool@snapshot | zfs recv -Fusv mypool-new/encryptedroot

    Die Übertragung verschlüsselter Datasets ist derzeit definitiv noch eine ZFS-Baustelle, und auch Dokumentation im eigenen Wiki hat hier leider noch Lücken, was die Nutzung von zfs-change-key usw. zur Anpassung von Schlüsseln betrifft (openzfs/zfs issue #12000 ist hier ein guter Einstiegspunkt, um sich die Probleme zu verdeutlichen). ;(

    Das obige Beispiel zur Übertragung eines gesamten Pool-Inhalts vom Root-Dataset ausgehend in die Dataset-Hierarchie eines anderen Pools ist meines Wissens derzeit (gerade) (noch) nicht möglich, man müsste notfalls über alle direkten Kind-Datasets iterieren (ich hatte vor über einem Jahr ein Problem mit den "zfs recv"-Filtern/-Parametern); entsprechende Tests liegen seit den eigenen letzten Migrationen allerdings allesamt noch auf einer TODO-Liste. (Eigene Backups gesamter Pools und Datasets „in die Cloud“ laufen derzeit – dank des konkurrenzlos günstigen Speicher-Angebots derzeit noch präferiert – via WebDAV, sodass sich dieses Problem hier nicht stellt, auch wenn obiges Szenario ZFS-Pool1→ZFS-Pool2/new-path langfristig erwünscht ist.)

    Ich freue mich allerdings schon über zusätzliche Erfahrungsberichte hier im Forum! ^^

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

    5 Mal editiert, zuletzt von m_ueberall ()

    Gefällt mir 1
  • Es grüßt doch täglich...


    Port wieder tot (am Ersatzswitch!), als ich Zuhause ankam, fing er aber nach ca. 1h ohne mein Zutun wieder zu Blinken an. Keine neuen Erkenntnisse im Log. Jetzt hängt wieder der alte Switch dran, aber mit einem neuen 12V Netzteil. Und nachher tausche ich noch das beschädigte Kabel aus. X/

    Port wieder tot ||

    • Neustart des GS108Tv2: Keine Änderung.
    • Netzwerkkabel ohne Überspannungsschutz der USV: Keine Änderung.

    Allerdings blinkte der Billigswitch am anderen Ende der Leitung wie ein Weihnachtsbaum in allen möglichen Farben. Sah aus wie ein Bootloop, also eventuell doch ein Problem mit der Stromversorgung am Billigswitch? Er hängt jetzt mal direkt an 230V. Wenn das immer noch nicht hilft, bleibt mir wirklich nur noch die Möglichkeit, den Billigswitch zum Test zu ersetzen. Entweder durch den baugleichen Reserveswitch oder einen GS108Tv2.


    Das macht langsam keinen Spaß mehr ;(

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Einmal editiert, zuletzt von KB19 ()

  • Das obige Beispiel zur Übertragung eines gesamten Pool-Inhalts vom Root-Dataset ausgehend in die Dataset-Hierarchie eines anderen Pools ist meines Wissens derzeit (gerade) (noch) nicht möglich, man müsste notfalls über alle direkten Kind-Datasets iterieren […]

    Damit wir uns nicht missverstehen: Aber das ist schon möglich…


    mypool -> otherpool/mypool


    Das mache ich nämlich seit fast einem Jahr mit den Backups :/


    Was tatsächlich nicht geht, vor allem wenn eine Verschlüsselung im Spiel ist: mypool -> otherpool


    Dementsprechend wäre im neuen Pool ein Pseudo-Root-Dataset, also eine weitere Ebene in der Hierarchie, definitiv sinnvoll.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Damit wir uns nicht missverstehen: Aber das ist schon möglich…

    mypool -> otherpool/mypool

    Das mache ich nämlich seit fast einem Jahr mit den Backups :/

    Was tatsächlich nicht geht, vor allem wenn eine Verschlüsselung im Spiel ist: mypool -> otherpool

    Hm, ich glaube, bei der Migration habe ich tatsächlich vor dem letzteren Problem gestanden und die "Kind-Datensets" dann einzeln in den neuen Pool auf die oberste Ebene transferiert. Mal die eigenen Logdateien durchforsten und die Notizen im Wiki abgleichen. Für Neuinstallationen halte ich inzwischen für die jeweils verwendeten Architekturen eine "Basispooldefinition" ([bpool*+]rpool) vor (mit der alles evtl. Existierende überschrieben wird), welche gleichzeitig als Testumgebung für neue Kernel-/ZFS-Treiber-Kombinationen dient, bevor diese Pakete in der Produktivumgebung verteilt werden. Individuelle Datasets sollten danach einzeln migrierbar sein.

    * leider noch nicht für aarch64/arm64, weil auf den ODROID N2+ standardmäßig Petitboot anstelle von Grub2 zum Einsatz kommt und ich nicht mit U-Boot herumkämpfen will

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • m_ueberall Wie gesagt, mein Wunschszenario geht auf jeden Fall…

    Bildschirmfoto_2022-05-14_16-55-21.png


    newpseudoroot (und alle Kinder) kann ich dann weiterhin gesammelt entsperren. Die Snapshots sind auch alle noch vorhanden. Und in Zukunft könnte ich newpseudoroot problemlos(er) in einen anderen Pool transferieren. Dann wäre es außerdem endlich identisch zur Backup-HDD und ich könnte sie notfalls 1:1 im System einbauen, indem ich den Pool umbenenne und (falls vorhanden) das RO-Flag entferne.


    (Und zukünftig werden weitere Datasets ausschließlich unterhalb von newpseudoroot angelegt. Außer ich brauche was temporäres zum Testen, dann wäre außerhalb natürlich trotzdem sinnvoll.)

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Einmal editiert, zuletzt von KB19 ()

  • Sucht ihr nicht einfach nur http://sanoid.net/ oder habe ich was übersehen?

    Das verwende ich bei Proxmox sowieso, aber unter TrueNAS (wo der zu vergrößernde Pool läuft) würde mir das keine Vorteile bringen. Vor allem geht es bei meinem Szenario um eine einmalige Sache :)

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Externer Inhalt twitter.com
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.

  • die nächste Burger-Generation entstammt dann von durch rotierenden Festplattenscheiben betriebenen Fleischwölfen ... 8o

    quasi Burger mit Schleudertrauma ;)

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • Man könnte sicherlich den vor dem Update erstellten Snapshot verwenden und es nochmals versuchen.

    Alternativ findet sich hier eine potenzielle Lösung (mehrere scrub-/clear-Durchläufe; Workaround: Oberverzeichnis verschieben): Repairing a Corrupted File or Directory

    Wenn beides nicht funktioniert, würde ich den Pool schon aus Sicherheitsgründen neu anlegen, wobei auch der Workaround nicht wirklich gefällt.

    Danke, soeben ausprobiert.


    Leider hat es aber nicht geholfen. Witzigerweise ist da laut ZFS nichts korrupt. ZFS ist grundsätzlich der Meinung, alles sei okay. Mehrfache Scrubs, clears, das eog Verzeichnis umbenannt, ... - alles unverändert. Das eog Verzeichnis lässt sich nur umbenennen, nicht verschieben, denn dafür müsste er ja das potenziell korrupte figures Verzeichnis lesen, woanders schreiben und die Quelle löschen - das geht nicht, weil "Datei oder Verzeichnis nicht gefunden".


    Das ist sowieso total weird:

    Die NVMe SSD ist auch okay: "SMART overall-health self-assessment test result: PASSED".


    Durch das Umbennenen des eog Verzeichnis konnte ich jetzt auf jeden Fall das Paket erstmal wieder installieren. Mal schauen ob ich noch eine anderweitige Lösung finde... ansonsten bleibt es halt so.

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

    2 Mal editiert, zuletzt von whoami0501 ()

    Verwirrend 1
  • m_ueberall


    Hast du einen speziellen Grund, warum du bei den fio-Parametern für deine Benchmarkliste --rwmixread=75 verwendest, statt des defaults 50 ?

    (yabs.sh belässt es ja z.B auch bei diesem Halbe/Halbe)

    Die ersten Benchmarkergebnisse, die hier im Forum veröffentlicht wurden und die Grundlage für die Vergleichstabelle legten, haben allesamt diesen Wert verwendet. Und von der Gesamt-Charakteristik der eigenen Anwendungen her überwiegen auch Lesezugriffe. Deswegen erschien es naheliegend, das einfach so fortzuführen.

    (Einen Konsens bzgl. der Gewichtung wird man eh' kaum finden.)

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

    Danke 1
  • Die ersten Benchmarkergebnisse, die hier im Forum veröffentlicht wurden und die Grundlage für die Vergleichstabelle legten, haben allesamt diesen Wert verwendet. Und von der Gesamt-Charakteristik der eigenen Anwendungen her überwiegen auch Lesezugriffe. Deswegen erschien es naheliegend, das einfach so fortzuführen.

    (Einen Konsens bzgl. der Gewichtung wird man eh' kaum finden.)

    Damit man deine Tabelle schneller finden kann, solltest du deine Tabelle besser mal mit in deiner Fußzeile mit aufnehmen.

  • Ich hab bei einem geteilten Ordner via SMB Share max 110MB/s Übertragungsgeschwindigkeit.

    Dies passiert auch ohne Parität wenn ich z.B. einen Order auf einer 1500MB/s NVMe SSD freigebe.
    Das Netzwerk habe ich mit iperf gemessen und hatte 900 MBit/s.
    Wo bleibt hier die Performance liegen?
    Das Problem besteht sowohl, wenn Windows der SMB Host ist, als auch wenn Unraid der SMB Host ist (mit und ohne weiteren SSD Cache).
    Der Client ist Windows 11.
    Hat jemand einen Tipp?