[Sammelthread] ZFS Stammtisch

Ist praktisch Frage an Radio Eriwan: Geht das
Im Prinzip geht es schon, manchmal halt nur teilweise, eingeschränkt oder garnicht

Bei Original ZFS gibt es Versionen wie v28 (die letzte kompatible mit Oracle Solaris) oder aktuell v45. Ein Pool kann da nur importiert werden, wenn die entsprechende Version bereits von Solaris unterstützt wird.

Open-ZFS basiert auf v28 mit Feature Flags. Als Version wird v5000 angezeigt damit es nie zu Problemen mit Oracle ZFS kommen kann. Prinzipiell sieht es so aus, dass ein Pool v5000 ohne aktivierte Features (kann man beim Anlegen des Pools einstellen) problemlos in aktuellen und älteren Free-BSD, Illumos, OSX und ZoL Versionen importiert werden kann. Dafür wurde das gemeinsame Open-ZFS Dach ja erfunden.

Wenn man Features aktiviert, so gibt es welche die unkritisch sind. Auch neue Funktionen wie Trim bewirken keine strukturellen Änderungen. Andere Features ändern die Struktur von ZFS mit der Folge dass diese Pools nur noch lesend geöffnet werden können. Allocation classes/special vdev ist ein Beispiel. Es gibt aber auch Features die nach Aktivierung dafür sorgen dass der Pool auf einem System dass dieses Feature nicht unterstützt gar nicht geöffnet werden können. ZFS encryption ist ein Beispiel.

Hinzu kommen manchmal Partitionierungsprobleme. FreeNas z.B. legt gerne eine Swap Partition auf jeder Platte an. Andere wollen lieber die ganze Platte sehen und können eventuell Probleme beim Import haben.

Entscheidend ist:
Wenn ein neues ZFS Feature auf den Markt kommt und man das aktiviert, kann es sein dass man Probleme beim Import in einer Vorgängerversion des OS oder auf anderen Plattformen hat. Features die bereits länger in Open-ZFS sind sollten keine Probleme beim Import auf anderen aktuellen Plattformen haben.


Spezielle vdevs
Dabei handelt es sich um das ZFS Feature "ZFS Allocation Classes" das neue vdev Typen neben den normalen basic, mirror, Z, L2arc und Slog bringt. Diese neuen vdevs sind gedacht um spezielle Datentypen wie Metadaten, kleine io oder dedup zu speichern. Dies ist ein neuer Ansatz um diese speziellen Datentypen mit besonders schnellen vdevs abzudecken. Insgesamt eine sehr intelligente Alternative zu Storage Tiering bei der man einzelne Dateien auf schnellere Arrays packen kann. ZFS deckt das oft zwar schon mit rambasierten Techniken ab (Arc Lesecache, RAM Schreibcache). Diese vdev Typen kommen aber mit weniger RAM zu ähnlichen Resultaten (hoffentlich, habe vor dazu eine Testreihe aufzusetzen)


siehe illumos: manual page: zpool.1m
-> Virtual Devices (vdevs)

Metadata Allocation Classes by don-brady · Pull Request #5182 · zfsonlinux/zfs · GitHub
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Schreibe mal bitte in zwei bis drei Sätzen, wie es aktuell ist und wie es sein soll. Mir fehlt die Übersicht.
 
an mich?

Wenn man unsicher ist:
Auflisten der Features eines Pools: zpool get all poolname | grep feature

Um zu sehen, welche Features ein Zielsystem unterstützt:
Dort bei einem aktuellen Pool (nach zpool upgrade) gleiches aufrufen.

Wenn beide Systeme ein gleiches Feature-Set (nur aktivierte Features zählen) haben,
geht ein Austausch problemlos. Ansonst: ausprobieren, bei Problemen auf das
Ursprungssystem zurückgehen und Daten per zfs send oder rsync schicken.
 
Schreibe mal bitte in zwei bis drei Sätzen, wie es aktuell ist und wie es sein soll. Mir fehlt die Übersicht.

Wenn du mich meinst: Derzeit zwei Proxmox Nodes im Cluster mit ZFS und Storage Replication. Backup derzeit auf normales Debian per rsync auf ein stinknormales Raid5 mdadm.

Geplant: Proxmox Nodes bleiben gleich. Backup stattdessen auf ein OmniOS mit napp-it und send/recv.
 
Habe meine NVMe SSD jetzt nochmal mit einem direkt installierten OmniOS getestet, also ohne ESXi.
Hier wird die SSD erkannt und sie wird nicht als fehlerhaft markiert.
Auf einem zweiten System erhalte ich bei Verwndung mit ESXi ebenfalls die Markierung als fehlerhaftes Gerät.
Es dürfte sich also um ein Problem beim pass-through handeln, oder?
20191004_125311.jpg
 
Wenn du mich meinst: Derzeit zwei Proxmox Nodes im Cluster mit ZFS und Storage Replication. Backup derzeit auf normales Debian per rsync auf ein stinknormales Raid5 mdadm.

Geplant: Proxmox Nodes bleiben gleich. Backup stattdessen auf ein OmniOS mit napp-it und send/recv.

Ja, Du warst gemeint. Verstanden.
Zfs send/recv sollte auch mit unterschiedlichen Versionen klar kommen, insofern guter Plan.
 
Habe meine NVMe SSD jetzt nochmal mit einem direkt installierten OmniOS getestet, also ohne ESXi.
Hier wird die SSD erkannt und sie wird nicht als fehlerhaft markiert.
Auf einem zweiten System erhalte ich bei Verwndung mit ESXi ebenfalls die Markierung als fehlerhaftes Gerät.
Es dürfte sich also um ein Problem beim pass-through handeln, oder?
Anhang anzeigen 477413

Hast du dann wieder 6.7 u3 verwendet ? Nicht dass das u3 Update damit ein Problem hat.
 
Ja wieder 6.7 u3, könnte aber mal u2 testen.
 
@snip0r: ich hab grad gestern zufällig eine 2TB Intel 660p per Passthrough in eine Windows-VM geklebt. Funktioniert soweit problemlos (bissi CrystalDiskMark drüber gejagt).

Als nächstes werde ich die mal in eine Solaris 11.4 VM hängen. Werde berichten.
 
Konnte bisher auch nur unter der omniOS VM diese Probleme beobachten.
 
Auf Solaris 11.4 klappt's jedenfalls auch nicht auf Anhieb. Solaris bootet nichtmal vernünftig durch. Nehme ich der VM die SSD wieder weg, ist wieder alles tutti.

Weird.
 
6.7U3 (auf der Testkiste).
 
Aktuell funktioniert NVMe passthrough eigentlich sehr gut. Die Probleme mit Optane vor ca 2 Jahren mit den Unixen Free-BSD und Illumos sehe ich aktuell nicht mehr. Damals konnte man durch Editieren der passthrough.map das Problem teilweise beheben.

Bleibt natürlich immer das Kompatibilitätsproblem. Passthrough ist nicht trivial. Bei Sata und besonders LSI SAS HBA passthrough klappt das seit Jahren extrem zuverlässig. Andere PCI-e Karten können gerne auch mal Ptobleme machen. Da ist der Rat dann, diese eben nicht zu nehmen. Bei NVMe sehe ich das auch so.

Bleibt die Frage, ob das ein Problem dieser einen Intel (Serie) ist, nur bei einem Mainboardtyp auftaucht und auch durch Editieren
der passthrough.map (google: esxi optane passthrough) nicht behoben werden kann.

In diesem Fall empfehle ich eine Mail an illumos-discuss. Da wird gerade am NVMe Treiber gearbeitet um NVMe hotplug zu integrieren. Vielleicht gibts da einen Tipp der Entwickler oder eine Anpassung des Treibers oder die Bitte um weitere Infos.

Alternativ das als einen Bug melden oder als Verbesserung wünschen
Issues - illumos
 
Unter 6.7U1 funktioniert es auch nicht. Hier wird die SSD noch als NVMe P4500/P4600 erkannt.

Eine 900p funktioniert ohne Probleme. Getestet habe ich das Ganze mit 2 verschiedenen supermicro Boards (x11ssl-cf und x10sdv-tln4f jeweils neuestes BIOS)

Solaris 11.4 VM funktioniert
Ubuntu 18.04 LTS VM funktioniert
Windiws Server 2019 VM funktioniert
omnios 151030 funktioniert nicht
omnios 151030 ohne ESXi funktioniert

Ein Eintrag in die passthrough.map mit "8086 a54 d3d0 false" hilft auch nicht

Wenn ich napp-it nutzen will bleibt mir jetzt wohl nur die Möglichkeit die SSD unter ESXi als Datastore an die omniOS zu hängen, oder?
 
Zuletzt bearbeitet:
Ich bin mir nicht sicher, ob OmniOS 151031 bloody bereits einen neuen NVMe Treiber enthält. Ist aber wahrscheinlich, da OmniOS NVMe hotplug für die nächste Stable für November angekündigt hat. Ein Versuch wärs wert. Dank BE kann man ja zurück oder dann auf 151032 stable updaten.

http://www.napp-it.org/doc/downloads/setup_napp-it_os.pdf

Ansonsten mal abwarten ob es eine Reaktion in illumos-discuss gibt.
 
Hatte ich leider vergessen zu erwähnen, aber das hatte ich direkt versucht nachdem Dein erster Hinweis dazu kam, leider ohne Erfolg.
 
Hi,
Ich habe recht viel Speicherplatz unter "USEDCHILD" stehen. Woran kann ich erkennen, was das genau ist?

Grüße
 
ah verstanden, alles was unter "/tank" ist, fällt unter child.

Andere Frage: Ich plane demnächst meinen Fileserver aufzurüsten und würde von aktuell 4*3TB und 2*4TB @ striped mirror auf 12*4TB umsteigen. Da ist die Frage, ob ich da bei Striped Mirror bleiben soll oder auf 3*RaidZ1 oder 3*RaidZ2 mit 4 HDDs umsteigen sollte. Das sollte alles als ein Pool zusammengefasst werden. Performance ist da nicht sooo entscheidend, da entweder 10Gbit-NIC und/oder der (geplante) Expander am H310 limitiert.

Backups würden dann auf einem anderen Server auf den 4*3TB gesichert werden, die dann definitiv in RaidZ1 laufen werden.
 
Zuletzt bearbeitet:
@Snip0r: bei mir laufen weder die 660p noch eine Samsung SM861 in einer Solaris 11.4 VM per Passthrough... hast Du irgendwas besonderes eingestellt?
 
Andere Frage: Ich plane demnächst meinen Fileserver aufzurüsten und würde von aktuell 4*3TB und 2*4TB @ striped mirror auf 12*4TB umsteigen. Da ist die Frage, ob ich da bei Striped Mirror bleiben soll oder auf 3*RaidZ1 oder 3*RaidZ2 mit 4 HDDs umsteigen sollte. Das sollte alles als ein Pool zusammengefasst werden. Performance ist da nicht sooo entscheidend, da entweder 10Gbit-NIC und/oder der (geplante) Expander am H310 limitiert.

Für einen reinen Fileserver würde ich bei 12 Platten 2 x Z2 vdev je 6 Platten machen, ergibt 32 TB nutzbar. Müssen 10 Platten nachgekauft werden, würde ich weniger Platten nehmen z.B. 6 x 8 TB.
 
Ich habe 12 Wechselslots und die MÜSSEN belegt werden. Einfach weil :fresse2:

Bei 12 HDDs mache ich mir ja schon Sorgen bezüglich Vibrationen. Reichen da noch die normalen WD Reds?
 
Nope, die sind da schon ausserhalb der Spec. Ich würde lieber auf größere Helium-Platten setzen. Weniger Teile, die Kaputtgehen können, laufruhiger, energieeffizienter.
 
Das weiß ich, aber es haben auch viele greens zu dutzenden am laufen.

Die Heliumplatten habe ich auch schon auf dem Schirm, aber es ändert nichts daran, dass ich meine 12 Schächte voll haben will :fresse:
 
Naja, ich hab auch 12 Schächte belegt: 6xHC530 (Raidz2) für einen Pool mit viel Kapazität (Ablage, Media, etc.) , 6xSM863/883 (3 Mirror-Pärchen) für einen Pool mit viel IO (VMs, permament genutzte Software, Datenbank-Tablespaces).
Mind. 1 Port will ich frei haben für Notfälle (zpool replace).
 
Zuletzt bearbeitet:
Muss gerade etwas Temporäres zusammenschustern, um ein System freizuhaben, wo Solaris auf dem Blech laufen kann.

Kann man

- Solaris auf ein USB-Volume installieren und dieses Volume ist außer dem Bootloader verschlüsselt?

- Wird eine (sehr) alte AMD Radeon 5450 ordentlich treiberseitig erkannt, so dass ein Bildschirm in Stand By gehen kann und das Energie-Management im Idle der Karte funktioniert?

Vielen Dank!
 
1.
Installieren auf einem USB Stick wird vermutlich gehen.
OS verschlüsseln wohl nicht (Man verschlüsselt je Dateisystem für User-Daten).

2.
Solaris wird von Oracle als Datacenter OS für die Top 500 der Börsen positioniert die eine Updategarantie für 15-20 Jahre benötigen. Primär läuft Solaris ohne grafische Oberfläche. Grafikkarte ist also zunächst mehr als egal. Installiert man die grafische Oberfläche, geht es da nicht um Multimedia/3D Performance oder gar Energiesparen sondern allenfalls um etwas Admin Komfort.

Als eher Nein, Nein
 
Das mit dem Einsatzzwecks des OS mir klar, mir geht es darum, dass die GPU, die ja eigentlich nur dafür da ist, dass das Mainboard bootet, nicht "sinnlos" im Hintergrund vor sich hinbrät, sondern wie eben unter Windows 2D-Idle-Desktop entsprechend runtertaktet.
 
Ich hatte die 5450 in nem Solarissystem, die lief problemlos inkl. Abschaltung des Bildschirms, aber ob die runtergetaktet hat? War ne Passivkarte, so arg viel kann die auch unter Volllast nicht picheln. Du sagst ja selbst, dass das nur als Provisorium herhalten muss, und dafür taugts.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh