Hi
Ich habe mir eine 2TB SM883 geholt, und würde gerne zwei Debian mit einem Hosting Panel und einer Nextclod aufsetzen. Auf einem ESXi mit napp-it. Die Daten für die beiden VMs würde ich gerne direkt per NFS zur Verfügung stellen.
Im Moment habe ich Nextcloud auf einer 500GB SSD. Einmal VMDK für OS, einmal VMDK gemountet mit den Daten.
Als ich das eingerichtet hatte, dachte ich es sei genug freier Speicher vorhanden mit meinen VMDKs. Ich hatte dann die Daten VMDK gefüllt, und blöderweise einen Snapshot vergessen, den ich dann nicht mehr konsolidieren konnte, weil die Daten VMDK nicht als selbständig markiert war. Ich habe es dann nochmals neu aufgesetzt; jetzt ist das Problem dass auf der SSD am Storage nur noch ~50 GB verfügbar sind, in Nextclod selber könnte ich aber noch 150GB rauf kopieren.
Aus dem Grund habe jetzt mal den Überlaufschutz auf napp-it noch auf 10% runter gedreht.
Aus diesem Grund möchte ich einfach zwei kleine Verzeichnisse, wo die beiden Debian mit KDE liegen. Diese sollen so weit anwachsen können wie nötig, wenn man mal einen Snapshot machen könnte wär das sicher auch nicht verkehrt. Dann möchte ich einen Pool auf napp-it mit den Daten.
Macht das Sinn mit einem Pool für Alles, oder einem Pool für Daten und einen für die VMs, oder zwei getrennte Pools für die Daten und einer für die VMs.
Am liebsten wäre mir die zweite Variante, ein kleiner Pool für die VMs und ein grosser gemeinsamer Pool für die Daten.
Wie gehe ich da am besten auf napp-it vor? So dass sicher nichts überlaufen kann, ich möglichst keinen Platz verschwende und dabei am flexibelsten bleibe? Die SSD ist mit 1920GB angegeben.
Gruss und danke
Ich habe mir eine 2TB SM883 geholt, und würde gerne zwei Debian mit einem Hosting Panel und einer Nextclod aufsetzen. Auf einem ESXi mit napp-it. Die Daten für die beiden VMs würde ich gerne direkt per NFS zur Verfügung stellen.
Im Moment habe ich Nextcloud auf einer 500GB SSD. Einmal VMDK für OS, einmal VMDK gemountet mit den Daten.
Als ich das eingerichtet hatte, dachte ich es sei genug freier Speicher vorhanden mit meinen VMDKs. Ich hatte dann die Daten VMDK gefüllt, und blöderweise einen Snapshot vergessen, den ich dann nicht mehr konsolidieren konnte, weil die Daten VMDK nicht als selbständig markiert war. Ich habe es dann nochmals neu aufgesetzt; jetzt ist das Problem dass auf der SSD am Storage nur noch ~50 GB verfügbar sind, in Nextclod selber könnte ich aber noch 150GB rauf kopieren.
Aus dem Grund habe jetzt mal den Überlaufschutz auf napp-it noch auf 10% runter gedreht.Aus diesem Grund möchte ich einfach zwei kleine Verzeichnisse, wo die beiden Debian mit KDE liegen. Diese sollen so weit anwachsen können wie nötig, wenn man mal einen Snapshot machen könnte wär das sicher auch nicht verkehrt. Dann möchte ich einen Pool auf napp-it mit den Daten.
Macht das Sinn mit einem Pool für Alles, oder einem Pool für Daten und einen für die VMs, oder zwei getrennte Pools für die Daten und einer für die VMs.
Am liebsten wäre mir die zweite Variante, ein kleiner Pool für die VMs und ein grosser gemeinsamer Pool für die Daten.
Wie gehe ich da am besten auf napp-it vor? So dass sicher nichts überlaufen kann, ich möglichst keinen Platz verschwende und dabei am flexibelsten bleibe? Die SSD ist mit 1920GB angegeben.
Gruss und danke
Zuletzt bearbeitet:
Typischerweise sieht ein Setup so aus
-Kleine Sata boot SSD ab 80 GB für ESXi und die OmniOS ZFS Storage VM
- alle anderen Platten werden idealerweise an OmniOS durchgereicht und dort direkt verwaltet. Bei NVMe Platten kann man sich überlegen, die per ESXi und vmdk zu verwalten und per vdisk durchzureichen, vor allem wenn man das flexibel partitionieren will oder wenn es Probleme mit NVMe Passthrough gibt.
- Ich würde zwei ZFS Pools anlegen. Einen High Performance aus NVMe für VMs und einen High Capacity für Filer und Backup aus Platten.
- Dateisysteme des NVMe ZFS Pools dann per NFS an ESXi geben und darauf VMs und Daten ablegen. Wenn man das Dateisystem auch per SMB freigibt hat man einfachen Zugriff auf die VMs inkl. ZFS Versionierung per "Windows vorherige Version".
Ein überlaufender ZFS Pool hat vor allem Performanceprobleme. Der "Überlaufschutz" per Reservierung verhindert dass das aus Versehen passiert und man flexibler reagieren kann als wenn alles voll ist man überlegen muss welche Snaps man löscht oder wie man in einem Copy on Write Dateisystem Platz schafft falls keine Snaps da sind.
-Kleine Sata boot SSD ab 80 GB für ESXi und die OmniOS ZFS Storage VM
- alle anderen Platten werden idealerweise an OmniOS durchgereicht und dort direkt verwaltet. Bei NVMe Platten kann man sich überlegen, die per ESXi und vmdk zu verwalten und per vdisk durchzureichen, vor allem wenn man das flexibel partitionieren will oder wenn es Probleme mit NVMe Passthrough gibt.
- Ich würde zwei ZFS Pools anlegen. Einen High Performance aus NVMe für VMs und einen High Capacity für Filer und Backup aus Platten.
- Dateisysteme des NVMe ZFS Pools dann per NFS an ESXi geben und darauf VMs und Daten ablegen. Wenn man das Dateisystem auch per SMB freigibt hat man einfachen Zugriff auf die VMs inkl. ZFS Versionierung per "Windows vorherige Version".
Ein überlaufender ZFS Pool hat vor allem Performanceprobleme. Der "Überlaufschutz" per Reservierung verhindert dass das aus Versehen passiert und man flexibler reagieren kann als wenn alles voll ist man überlegen muss welche Snaps man löscht oder wie man in einem Copy on Write Dateisystem Platz schafft falls keine Snaps da sind.
Hi
NVMe unterstützt mein System leider nicht. Du hast irgendwo auch mal angemerkt, dass durchgereichter Datastore auf NVMe nicht zu empfehlen ist, wenn ich mich recht erinnere.
Ja, für ESXi und napp-it habe ich je eine bestehende SSD. An napp-it habe ich einen Perc H310 durchgereicht, mit 3 Platten und 2 SSD atm. Hätte ich vielleicht erwähnen sollen, sry.
Es geht auf der neuen SSD am HBA also nur um die 2 VMs: Hosting Panel und Nextcloud. Das soll mit den Daten auf eine SSD. So war das gemeint.
NVMe unterstützt mein System leider nicht. Du hast irgendwo auch mal angemerkt, dass durchgereichter Datastore auf NVMe nicht zu empfehlen ist, wenn ich mich recht erinnere.
Ja, für ESXi und napp-it habe ich je eine bestehende SSD. An napp-it habe ich einen Perc H310 durchgereicht, mit 3 Platten und 2 SSD atm. Hätte ich vielleicht erwähnen sollen, sry.
Es geht auf der neuen SSD am HBA also nur um die 2 VMs: Hosting Panel und Nextcloud. Das soll mit den Daten auf eine SSD. So war das gemeint.
Weiter vorne hattest du es aber doch mit dem Cache erklärt wieso die Performance beim Schreiben höher sein sollte/könnte. Jetzt sagst du bei großen Dateien/Blöcken, ist der Cache überflüssig.
Also wie gesagt ich rede von großen Dateien, 20GB und mehr. Auf das bezieht sich das alles was ich an Schreib und Leseraten bei mir erreiche. Deine Erklärung mag für kleine Dateien Sinn ergeben. Ist habe aber genau das Gegenteil, also kann es daran bei mir nicht liegen.
Und wenn ich einen komplett neuen, leeren Pool befülle mit Daten, so gehe ich jetzt einfach mal davon aus dass ZFS die Daten nicht extra völlig wild verteilt damit die Performance beim Lesen dann absichtlich schlecht ist.
Also nochmal weil das vielleicht nicht klar geworden ist. Leerer, neuer Pool, wird ausschließlich mit großen Dateien (20GB und mehr) befüllt. Wenn ich genau diese Dateien dann lesen will, direkt nachdem ich sie geschrieben habe ist es bei mir langsam. Langsamer als beim Schreiben. Ich seh nicht wo ZFS bei diesen Daten die Schwierigkeit haben sollte beim Lesen. Ich denke bei einem leeren, neuen Pool kann ich davon ausgehen dass die Blöcke die zu den einzelnen Dateien gehören auf den Platten auch nach beieinander liegen und nicht absichtlich schon beim Schreiben fragmentiert wird. Dies würde ja im übrigen auch die SChreibrate ausbremsen.
Werde versuchem dem ganzen noch weiter auf den Grund zu gehen. Bin schon extra von 128K auf 1M umgestiegen eben wegen den großen Dateien. Dass ein freier 1M Block bei einem vollen pool mal weiterweg liegen kann, also von der Warscheinlichkeit her, also weiter als ein freier 128K Block ist nachvollziehbar . Aber in erster Linie würde das ja die Performance beim Schreiben verringern und die war bei mir immer noch am Gbit Limit auch bei ~90% Füllstand.
Zuletzt bearbeitet:
Ein Cache ist eine technische Lösung um eine langsames System wie z.B. mechanische Platten an ein schnelles System anzubinden. Die Art und Weise wie ein Cache funktioniert kann bestimmte Vorgänge beschleunigen, andere nicht.
Der rambasierte ZFS Schreibcache sorgt in erster Linie dafür dass nach Möglichkeit keine kleinen Schreibvorgänge (z.B. 4-32k commits) entstehen da dieser massive Performanceprobleme haben. Im Multiuserbetrieb gehen viele Schreibvorgänge in den Cache (sehr schnell) und werden dann verzögert geschrieben ohne dass der Client warten muss. Er verbessert als in erster Linie Latenz und vermeidet dazu kleine Writes soweit wie möglich.
Beim Schreiben einer großen Datei, egal ob 10 MB oder 20 GB sieht die Situation anders aus. So ein Schreibvorgang geht in den Schreibcache, wird da in recsize Blöcke aufgeteilt und geschrieben. Ist die zu schreibende Datei größer als der halbe Schreibcache im single User Zugriff, so erhält man idealerweise die sequentielle Schreibperformance des Pools beim Schreiben über den Cache. Aus Sicht der Datenpool Performance gibt es keinen riesigen Unterschied ob der Recsize Block 512k oder 1M ist. Bei 128k mag es minimal schlechter sein dafür sinkt eventuell die Leseperformance bei großer recsize da man immer recsize Blöcke lesen muss auch wenn man nur einen kleinen Datenhappen braucht. In beiden Fällen wird ein Pool nahe seiner sequentiellen Performance liegen und die ist bei einem guten ZFS Pool immer schneller als die Netzanbindung und sequentiell meist auch schneller als eine übliche Cache SSD. Je nach Schreibvorgang kann es auch passieren dass beim Schreiben nur der schnelle Cache beteiligt ist während beim Lesen fast ausschließlich von Platte gelesen werden muss weil die Daten nicht gecacht sind (Sequentielle Daten werden nicht gecacht, allenfalls hilft read ahead bei l2arc etwas.
vgl Artikel zum ZFS Schreibache z.B. http://dtrace.org/blogs/ahl/2014/02/10/the-openzfs-write-throttle/
Gute Einblicke gibts auch über die Open-ZFS Doklumente unter https://openzfs.org/wiki/OpenZFS_Developer_Summit
Insgesamt optimiert ZFS nicht auf einzelne Videodatei sondern will dafür sorgen dass im Schnitt alle Zugriffe gut optimiert sind. Die Platten werden also nicht sequentiell befüllt wie es bei einer Videodatei am schnellsten wäre, sondern Daten werden über die vdevs verteilt.
Der rambasierte ZFS Schreibcache sorgt in erster Linie dafür dass nach Möglichkeit keine kleinen Schreibvorgänge (z.B. 4-32k commits) entstehen da dieser massive Performanceprobleme haben. Im Multiuserbetrieb gehen viele Schreibvorgänge in den Cache (sehr schnell) und werden dann verzögert geschrieben ohne dass der Client warten muss. Er verbessert als in erster Linie Latenz und vermeidet dazu kleine Writes soweit wie möglich.
Beim Schreiben einer großen Datei, egal ob 10 MB oder 20 GB sieht die Situation anders aus. So ein Schreibvorgang geht in den Schreibcache, wird da in recsize Blöcke aufgeteilt und geschrieben. Ist die zu schreibende Datei größer als der halbe Schreibcache im single User Zugriff, so erhält man idealerweise die sequentielle Schreibperformance des Pools beim Schreiben über den Cache. Aus Sicht der Datenpool Performance gibt es keinen riesigen Unterschied ob der Recsize Block 512k oder 1M ist. Bei 128k mag es minimal schlechter sein dafür sinkt eventuell die Leseperformance bei großer recsize da man immer recsize Blöcke lesen muss auch wenn man nur einen kleinen Datenhappen braucht. In beiden Fällen wird ein Pool nahe seiner sequentiellen Performance liegen und die ist bei einem guten ZFS Pool immer schneller als die Netzanbindung und sequentiell meist auch schneller als eine übliche Cache SSD. Je nach Schreibvorgang kann es auch passieren dass beim Schreiben nur der schnelle Cache beteiligt ist während beim Lesen fast ausschließlich von Platte gelesen werden muss weil die Daten nicht gecacht sind (Sequentielle Daten werden nicht gecacht, allenfalls hilft read ahead bei l2arc etwas.
vgl Artikel zum ZFS Schreibache z.B. http://dtrace.org/blogs/ahl/2014/02/10/the-openzfs-write-throttle/
Gute Einblicke gibts auch über die Open-ZFS Doklumente unter https://openzfs.org/wiki/OpenZFS_Developer_Summit
Insgesamt optimiert ZFS nicht auf einzelne Videodatei sondern will dafür sorgen dass im Schnitt alle Zugriffe gut optimiert sind. Die Platten werden also nicht sequentiell befüllt wie es bei einer Videodatei am schnellsten wäre, sondern Daten werden über die vdevs verteilt.
Nochmal das Problem ist Beim lesen nicht beim Schreiben. Über welche vdevs soll zfs verteilen wenn man nur eines hat?
die Platten machen sequentiell einzelnt etwa 200mb. Bei einem raidz2 aus 4 Platten wären das im Idealfall 400mb. Ich habe aber nichtmal ein Viertel davon zumindest nicht beim lesen über smb. Und wenn du denkst es liegt am Cache ich kann auch gerne 50 oder 100gb am Stück schreiben und schauen ob die Performance auch da an gibt Limit bleibt. Da sollte der 16GB RAM ja dann wohl erschöpft sein.
das Hauptproblem bleibt aber weiterhin die sehr schlechte Performance beim lesen. Ich meine du hattest auch mal gesagt dass lesen schneller wäre da dort keine parität berechnet werden muss.
Ich könnte auf dem Server selbst ja mal eine Datei lesen wenn er dort dann hohe Datenraten hat muss das Problem sowieso woanders liegen
die Platten machen sequentiell einzelnt etwa 200mb. Bei einem raidz2 aus 4 Platten wären das im Idealfall 400mb. Ich habe aber nichtmal ein Viertel davon zumindest nicht beim lesen über smb. Und wenn du denkst es liegt am Cache ich kann auch gerne 50 oder 100gb am Stück schreiben und schauen ob die Performance auch da an gibt Limit bleibt. Da sollte der 16GB RAM ja dann wohl erschöpft sein.
das Hauptproblem bleibt aber weiterhin die sehr schlechte Performance beim lesen. Ich meine du hattest auch mal gesagt dass lesen schneller wäre da dort keine parität berechnet werden muss.
Ich könnte auf dem Server selbst ja mal eine Datei lesen wenn er dort dann hohe Datenraten hat muss das Problem sowieso woanders liegen
Schreibcache ist bei OpenZFS per default 10% RAM, max 4GB. Bei 16GB RAM also 1,6 GB wobei nur die Hälfte aktell Cache ist und die andere Hälfte gerade dabei ist den vorherigen Cache-Inhalt auf Platte zu schreiben. Lesecache ca 80% from freien Rest und hilft bei Video praktisch nicht da er keine sequentielle Daten cacht.
Bleibt allerdings das Problem dass 100 MB/s bei einem Raid-Z2 aus 4 Platten zu niedrig ist. Da ZFS grundsätzlich eher durch iops als pure sequentielle Leistung begrenzt wird, kann man nicht von 200 MB/s ausgehen sondern eher von 100-150 MB/s je Platte. Sollte dann aber bei 4 Z2 Platten (2 Datenplatten) doch bei 200 MB/s aufwärts liegen.
Um wenigstens einzugrenzen ob das Problem eher an ZFS oder an SMB bzw am Netz/Treibern liegt, könnte man einen zunächst einfachen dd Benchmark laufen lassen, Menü Pool > Benchmark.
ps
was für eine Netzwerkkarte ist das übrigens
Ich hatte bei 10G Intel Karten schon mal das Problem dass ich die neuesten Intel Treiber von deren Homepage nehmen musste statt der Windows Treiber sonst ging die Lese Performance nicht über 100 MB/s. Auch brachte das Deaktivieren von int-throttelling unter Windows erheblich Performance.
vgl https://napp-it.org/doc/downloads/performance_smb2.pdf
Bleibt allerdings das Problem dass 100 MB/s bei einem Raid-Z2 aus 4 Platten zu niedrig ist. Da ZFS grundsätzlich eher durch iops als pure sequentielle Leistung begrenzt wird, kann man nicht von 200 MB/s ausgehen sondern eher von 100-150 MB/s je Platte. Sollte dann aber bei 4 Z2 Platten (2 Datenplatten) doch bei 200 MB/s aufwärts liegen.
Um wenigstens einzugrenzen ob das Problem eher an ZFS oder an SMB bzw am Netz/Treibern liegt, könnte man einen zunächst einfachen dd Benchmark laufen lassen, Menü Pool > Benchmark.
ps
was für eine Netzwerkkarte ist das übrigens
Ich hatte bei 10G Intel Karten schon mal das Problem dass ich die neuesten Intel Treiber von deren Homepage nehmen musste statt der Windows Treiber sonst ging die Lese Performance nicht über 100 MB/s. Auch brachte das Deaktivieren von int-throttelling unter Windows erheblich Performance.
vgl https://napp-it.org/doc/downloads/performance_smb2.pdf
Zuletzt bearbeitet:
Ich hole die Frage noch mal hoch, keiner ‘ne Idee zu dem Status?
Beitrag im Thema 'ZFS Stammtisch'
https://www.hardwareluxx.de/community/threads/zfs-stammtisch.570052/post-28121294
Beitrag im Thema 'ZFS Stammtisch'
https://www.hardwareluxx.de/community/threads/zfs-stammtisch.570052/post-28121294
Der Pool mit dem vdev ist offline, die Platten sind verfügbar
Ich würde mal folgendes versuchen, in der Reihenfolge
- Log lesen nach Auffälligkeiten (System > Log)
- Pool clear error (Menü Pools > clear)
- Solarish Fehlermanager abfragen (System > Fault bzw System > Faults > repair)
- pool export + import
- reboot
Habe es jetzt gerade noch mal getestet, scrub job manuell gestartet via 'run now', ein zpool status zeigt keinerlei Probleme an.
Auch mehrfaches manuelle Ausführen des alert jobs führt zu keiner email mit Fehlermeldungen während der scrub läuft. Habe
auch noch mal in der zpool history geschaut, sowie in den Jobs logs. Die einzige Koinzidenz ist irgendwie die exakt gleiche Startzeit
(Der Autojob läuft jede Minute). Vielleicht irgendeine race condition die dem napp-it alert Job was vorgaukelt?
Habe einfach keine Melodie darauf. Würde ein minütlich laufender alert Job den dann auch jede Minute weiter den Fehler melden
oder wird dies nur einmal initial beim Auftreten des Fehlers getan?
root@storage01:/# zpool history storage | grep scrub
2018-08-30.17:38:59 zpool scrub storage
2020-12-06.03:00:03 zpool scrub storage
2021-01-03.03:00:03 zpool scrub storage
2021-02-07.03:00:03 zpool scrub storage
2021-02-17.09:53:53 zpool scrub storage
zeitgleich die letzte Ausführung des alert jobs:
Habe den alert job jetzt mal von minütlich auf alle 15;30;45 umgeplant.
Ergänzung:
Habe jetzt noch weiter alles mögliche durchsucht, es gibt nur historische Altlasten via fmdump, diese lassen sich auch
nicht via fmadm clear entfernen. Da ja nichts offen ist via fmadm, was eine Intervention benötigen würde.
root@storage01:/var/fm/fmd# fmadm faulty
root@storage01:/var/fm/fmd# fmadm list
root@storage01:/var/fm/fmd# fmadm list-alert
root@storage01:/var/fm/fmd# fmadm list-defect
root@storage01:/var/fm/fmd# fmadm list-fault
root@storage01:/var/fm/fmd#
root@storage01:/var/fm/fmd# fmdump
TIME UUID SUNW-MSG-ID EVENT
Nov 20 16:55:54.8691 1ee49ddb-d801-42ac-9d51-9f2e93f9ed16 ZFS-8000-QJ Diagnosed
Nov 20 17:22:09.7791 1ee49ddb-d801-42ac-9d51-9f2e93f9ed16 FMD-8000-4M Repaired
Nov 20 17:22:09.7861 1ee49ddb-d801-42ac-9d51-9f2e93f9ed16 FMD-8000-6U Resolved
Nov 20 17:24:55.0495 4661ed57-6619-4c7e-8c97-8440ff533f87 ZFS-8000-QJ Diagnosed
Nov 20 17:41:53.5309 4661ed57-6619-4c7e-8c97-8440ff533f87 FMD-8000-4M Repaired
Nov 20 17:41:53.5425 4661ed57-6619-4c7e-8c97-8440ff533f87 FMD-8000-6U Resolved
Nov 28 11:27:37.3563 446f695b-5c29-4516-a93d-bed1f7a5f4a5 NET-8000-39 Diagnosed
Nov 28 11:28:03.7515 6a4e3784-589b-4d3a-8d57-a07356e70afc NET-8000-2N Diagnosed
Nov 28 11:28:03.7536 446f695b-5c29-4516-a93d-bed1f7a5f4a5 FMD-8000-4M Repaired
Nov 28 11:28:03.7540 446f695b-5c29-4516-a93d-bed1f7a5f4a5 FMD-8000-6U Resolved
Nov 28 11:38:03.7534 6a4e3784-589b-4d3a-8d57-a07356e70afc FMD-8000-4M Repaired
Nov 28 11:38:03.7540 6a4e3784-589b-4d3a-8d57-a07356e70afc FMD-8000-6U Resolved
/var/adm/messages zeigt ebenfalls rein gar nichts
Wenn ich die Solaris Doku richtig deute, ist OFFLINE auch ein rein administrativer Status ist,
welcher systemseitig so nicht automatisch vergeben wird.
Auch mehrfaches manuelle Ausführen des alert jobs führt zu keiner email mit Fehlermeldungen während der scrub läuft. Habe
auch noch mal in der zpool history geschaut, sowie in den Jobs logs. Die einzige Koinzidenz ist irgendwie die exakt gleiche Startzeit
(Der Autojob läuft jede Minute). Vielleicht irgendeine race condition die dem napp-it alert Job was vorgaukelt?
Habe einfach keine Melodie darauf. Würde ein minütlich laufender alert Job den dann auch jede Minute weiter den Fehler melden
oder wird dies nur einmal initial beim Auftreten des Fehlers getan?
root@storage01:/# zpool history storage | grep scrub
2018-08-30.17:38:59 zpool scrub storage
2020-12-06.03:00:03 zpool scrub storage
2021-01-03.03:00:03 zpool scrub storage
2021-02-07.03:00:03 zpool scrub storage
2021-02-17.09:53:53 zpool scrub storage
zeitgleich die letzte Ausführung des alert jobs:
Habe den alert job jetzt mal von minütlich auf alle 15;30;45 umgeplant.
Code:
pool: rpool
state: ONLINE
scan: scrub repaired 0 in 1m16s with 0 errors on Sun Feb 14 22:01:18 2021
config:
NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
c3t0d0 ONLINE 0 0 0
errors: No known data errors
pool: storage
state: ONLINE
scan: scrub in progress since Wed Feb 17 09:53:53 2021
169G scanned out of 3.95T at 194M/s, 5h41m to go
0 repaired, 4.17% done
config:
NAME STATE READ WRITE CKSUM
storage ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
c0t5000CCA291E18BABd0 ONLINE 0 0 0
c0t5000CCA291E15EC2d0 ONLINE 0 0 0
logs
c3t1d0 ONLINE 0 0 0
errors: No known data errorsErgänzung:
Habe jetzt noch weiter alles mögliche durchsucht, es gibt nur historische Altlasten via fmdump, diese lassen sich auch
nicht via fmadm clear entfernen. Da ja nichts offen ist via fmadm, was eine Intervention benötigen würde.
root@storage01:/var/fm/fmd# fmadm faulty
root@storage01:/var/fm/fmd# fmadm list
root@storage01:/var/fm/fmd# fmadm list-alert
root@storage01:/var/fm/fmd# fmadm list-defect
root@storage01:/var/fm/fmd# fmadm list-fault
root@storage01:/var/fm/fmd#
root@storage01:/var/fm/fmd# fmdump
TIME UUID SUNW-MSG-ID EVENT
Nov 20 16:55:54.8691 1ee49ddb-d801-42ac-9d51-9f2e93f9ed16 ZFS-8000-QJ Diagnosed
Nov 20 17:22:09.7791 1ee49ddb-d801-42ac-9d51-9f2e93f9ed16 FMD-8000-4M Repaired
Nov 20 17:22:09.7861 1ee49ddb-d801-42ac-9d51-9f2e93f9ed16 FMD-8000-6U Resolved
Nov 20 17:24:55.0495 4661ed57-6619-4c7e-8c97-8440ff533f87 ZFS-8000-QJ Diagnosed
Nov 20 17:41:53.5309 4661ed57-6619-4c7e-8c97-8440ff533f87 FMD-8000-4M Repaired
Nov 20 17:41:53.5425 4661ed57-6619-4c7e-8c97-8440ff533f87 FMD-8000-6U Resolved
Nov 28 11:27:37.3563 446f695b-5c29-4516-a93d-bed1f7a5f4a5 NET-8000-39 Diagnosed
Nov 28 11:28:03.7515 6a4e3784-589b-4d3a-8d57-a07356e70afc NET-8000-2N Diagnosed
Nov 28 11:28:03.7536 446f695b-5c29-4516-a93d-bed1f7a5f4a5 FMD-8000-4M Repaired
Nov 28 11:28:03.7540 446f695b-5c29-4516-a93d-bed1f7a5f4a5 FMD-8000-6U Resolved
Nov 28 11:38:03.7534 6a4e3784-589b-4d3a-8d57-a07356e70afc FMD-8000-4M Repaired
Nov 28 11:38:03.7540 6a4e3784-589b-4d3a-8d57-a07356e70afc FMD-8000-6U Resolved
/var/adm/messages zeigt ebenfalls rein gar nichts
Wenn ich die Solaris Doku richtig deute, ist OFFLINE auch ein rein administrativer Status ist,
welcher systemseitig so nicht automatisch vergeben wird.
Zuletzt bearbeitet:
Ein Alert Job wird bei weiterbestehendem gleichen Fehler nur einmal pro Tag eine Alert Mail verschicken, egal wie oft man den Job triggert. Auch ein Scrub kann nur einmal laufen und für den gleichen Pool nicht mehrfach angestoßen werden.
Was das vdev offline angestoßen hat ist im Nachhinein ohne Log Information schwer nachvollziehbar.
Was das vdev offline angestoßen hat ist im Nachhinein ohne Log Information schwer nachvollziehbar.
the_pi_man
Enthusiast
Hatte ich befürchtet... Danke!
Das bringt mich aber zur nächsten Frage:
Kann ich mit TrueNAS einen Pool anlegen und den dann mit Solaris als 2ten Pool zu importieren um die Altdaten etwas zügiger verschieben zu können?
Ja, in einem perfekten Universum spiele ich das Backup des alten Pools auf dem neuen ein...
Das bringt mich aber zur nächsten Frage:
Kann ich mit TrueNAS einen Pool anlegen und den dann mit Solaris als 2ten Pool zu importieren um die Altdaten etwas zügiger verschieben zu können?
Ja, in einem perfekten Universum spiele ich das Backup des alten Pools auf dem neuen ein...
Zuletzt bearbeitet:
Elektromat
Experte
Hallo zusammen,
habe aktuell einen Pool, welcher ein nicht mehr verfügbares SLOG besitzt.
Kurze Info wäre super, wie ich das aus dem bestehenden Pool entfernen kann. Es steht auf REMOVED
Wenn man versucht es zu entfernen kommt die Meldung:
cannot remove device(s): log device has unplayed intent logs
Export und Import mit import with missing log device (-m) bleibt das fehlende Dev wie beschreiben nach dem Import vorhanden.
Wie wäre das richtige vorgehen zum entfernen, da nicht mehr existent/ Pool degraded.
Danke und Grüße
Elektromat
habe aktuell einen Pool, welcher ein nicht mehr verfügbares SLOG besitzt.
Kurze Info wäre super, wie ich das aus dem bestehenden Pool entfernen kann. Es steht auf REMOVED
Wenn man versucht es zu entfernen kommt die Meldung:
cannot remove device(s): log device has unplayed intent logs
Export und Import mit import with missing log device (-m) bleibt das fehlende Dev wie beschreiben nach dem Import vorhanden.
Wie wäre das richtige vorgehen zum entfernen, da nicht mehr existent/ Pool degraded.
Danke und Grüße
Elektromat
Elektromat
Experte
Habe hierzu folgendes gefunden:
https://unix.stackexchange.com/questions/130846/how-to-remove-broken-zil-disk-from-zfs-pool
Wäre dies der richtige Weg? Bzw. funktioniert das so unter Solaris 11.4?
Möchte vermeiden das durch falsch angewendetes vorgehen weitere Daten verloren gehen, also abgesehen von dem fehlenden Slog dev.
Napp-IT bietet folgende Optionen:
Ist es mit Napp-IT realisierbar ein REMOVED state Slog dev zu entfernen, welches dauerhaft nicht mehr verfügbar ist?
Oder sollte man testen mit
# zpool clear poolname
Dies entfernt nur die bestehenden Log Einträge zum Pool, Daten bleiben erhalten, richtig?
# zpool remove poolname dev_name_slogdev
Sonst würde mir nur einfallen in einem Stage System einen Pool anzulegen mit virtuellen Datenträgern, und zu testen, wie das verhalten wäre, wenn einzelne Datenträger nicht mehr verfügbar sind.
https://unix.stackexchange.com/questions/130846/how-to-remove-broken-zil-disk-from-zfs-pool
Wäre dies der richtige Weg? Bzw. funktioniert das so unter Solaris 11.4?
Möchte vermeiden das durch falsch angewendetes vorgehen weitere Daten verloren gehen, also abgesehen von dem fehlenden Slog dev.
Napp-IT bietet folgende Optionen:
Ist es mit Napp-IT realisierbar ein REMOVED state Slog dev zu entfernen, welches dauerhaft nicht mehr verfügbar ist?
Oder sollte man testen mit
# zpool clear poolname
Dies entfernt nur die bestehenden Log Einträge zum Pool, Daten bleiben erhalten, richtig?
# zpool remove poolname dev_name_slogdev
Sonst würde mir nur einfallen in einem Stage System einen Pool anzulegen mit virtuellen Datenträgern, und zu testen, wie das verhalten wäre, wenn einzelne Datenträger nicht mehr verfügbar sind.
Ein Slog (funktionierend oder removed) kann man normalerweise with disk > remove (zpool remove) entfernen. Hier scheint das Probleme zu machen. Der normale Weg wäre jetzt neustart + zpool clear + erneuter Versuch das Slog zu entfernen.
Man könnte jetzt noch ein Disk > Replace versuchen um das Slog zu ersetzen. Klappt das auch nicht würde ich den Pool als "problematisch" kennzeichnen - sollte eigentlich nicht passieren. Sicherheitshalber würde ich da Backup + pool recreate + restore machen.
Man könnte jetzt noch ein Disk > Replace versuchen um das Slog zu ersetzen. Klappt das auch nicht würde ich den Pool als "problematisch" kennzeichnen - sollte eigentlich nicht passieren. Sicherheitshalber würde ich da Backup + pool recreate + restore machen.
Elektromat
Experte
Tatsächlich war das fehlende Slog Device im Pool etwas störrisch. Es hat sich auch nach einem Reboot / Clear nicht entfernen lassen. Ein Disk Replace hat ihn wieder funktionstüchtig gemacht.
Bin mal gespannt was mir der anstehende Scrub berichtet.
Bin mal gespannt was mir der anstehende Scrub berichtet.
CommanderBond
Enthusiast
- Mitglied seit
- 16.04.2012
- Beiträge
- 703
Spiele grade etwas herum mit der ZFS Funktion Replications. Allerdings verstehe ich das Prinzip dahinter nicht so ganz. Ich habe nun mein Filesystem auf einen zweiten Server repliziert. Allerdings sind meine ganzen Snapshots jetzt nicht da die ich auf dem Quellsystem habe. Werden die nicht mitgesichert?
Spiegelt ein Snapshot immer nur den aktuellen Zustand wieder? Oder sind in einem Snapshot selbst auch alle vergangenen zu dieser Zeit existierenden Snapshots mit drin?
Spiegelt ein Snapshot immer nur den aktuellen Zustand wieder? Oder sind in einem Snapshot selbst auch alle vergangenen zu dieser Zeit existierenden Snapshots mit drin?
Trambahner
Urgestein
Nur den aktuellen Zustand von dem Moment, wo ein Snap erstellt wurde.
D.h. Du musst die Snaps davor ebenso übertragen. Oder bei ZFS send -R verwenden, dann werden alle Snaps davor mit übertragen.
D.h. Du musst die Snaps davor ebenso übertragen. Oder bei ZFS send -R verwenden, dann werden alle Snaps davor mit übertragen.
CommanderBond
Enthusiast
- Mitglied seit
- 16.04.2012
- Beiträge
- 703
Kann ich einen älteren Snap auch nachträglich noch "hinterherschicken" ?
Trambahner
Urgestein
Hab ich noch nie ausprobiert.
Grundsätzlich: ja, natürlich. Bin mir nicht sicher, aber ich glaub das kannst Du dann nicht für inkrementelles Snap send/receive nutzen, sondern liegt unabhängig davon und braucht auch entsprechend vollständig den im nachträglichen älteren Snap allokierten Speicherplatz nochmal. => Bantha Poodo bei großen Datasets.
Wenn Du nicht mit inkrementellem send/receive arbeitest sondern stets vollständige Snaps schickst, dann sollte es egal sein. Aber ständig vollständige Snaps für Backupzwecke zu senden, macht eigentlich keinen Sinn.
Grundsätzlich: ja, natürlich. Bin mir nicht sicher, aber ich glaub das kannst Du dann nicht für inkrementelles Snap send/receive nutzen, sondern liegt unabhängig davon und braucht auch entsprechend vollständig den im nachträglichen älteren Snap allokierten Speicherplatz nochmal. => Bantha Poodo bei großen Datasets.
Wenn Du nicht mit inkrementellem send/receive arbeitest sondern stets vollständige Snaps schickst, dann sollte es egal sein. Aber ständig vollständige Snaps für Backupzwecke zu senden, macht eigentlich keinen Sinn.
Zuletzt bearbeitet:
CommanderBond
Enthusiast
- Mitglied seit
- 16.04.2012
- Beiträge
- 703
Muss mich damit nochmal beschäftigen, das Wording verwirrt mich auch. Was passiert wenn ich nach einem inkrementellen Snap den "Basissnap" lösche? Müsste doch im Grunde nix weiter passieren oder weil die Daten ja von dem späteren Snap dann "festgehalten" werden?
Gen8 Runner
Experte
- Mitglied seit
- 12.08.2015
- Beiträge
- 1.148
Dasselbe hatte ich mich auch schon gefragt vor einiger Zeit und hier mal diskutiert: https://www.truenas.com/community/t...and-the-way-how-safe-it-is.87243/#post-604969
Grundsätzlich ist ein Snapshot ein "Inhaltsverzeichnis" sämtlicher Datenblöcke von deinem Dateisystem zu bestimmten Zeitpunkten. Und nur je nachdem, auf welches Datum diese abzielen, werden diese Datenblöcke auch angesprochen und dem Snapshot zugeordnet.
Aber so wie du das genannt hattest, ist es auch grundsätzlich zu verstehen.
Du löscht einen alten Snapshot, jedoch sind dort noch jede Menge Daten eines neueren Snapshots enthalten. Diese werden dann natürlich beibehalten und nur die Daten auch wirklich gelöscht, die sich in keinerlei Snapshot bzw. aktiv auf dem Dateisystem mehr befinden.
Prinziell muss man sich zwei Verhaltensweisen vergegenwärtigen.
1. Copy on Write
Wenn man in einer Textdatei Hans zu Haus ändert wurde bei älterene Dateisystemen nur die betroffene Information (also idealerweise 1 Byte) geändert. Sun wollte das bei ZFS nicht mehr so haben weil wenn beim Ändern der Datei ein Absturz erfolgt nachdem die Datei geändert wurde aber bevor die Metadaten auf den neuen Stand gebracht wurden war das Dateisystem kaputt (ok passierte eher bei Ändern von Hans zu Hänschen).
ZFS schreibt daher immer den betroffenen Datenblock (in recsize, z.B. 128k, variabel kleiner) neu. Ist das komplett erfolgreich, ist der neue Datenblock aktiv, ansonst der vorherige (kein korruptes Dateisystem per Design). Der alte Datenblock wird dann für weitere Nutzung freigegeben es sei denn man hat einen Snap gesetzt. Der friert dann den Datenblock ein. Daher wird ein ZFS Snap ja auch ohne Zeitverzug erstellt (ist nicht Ergebnis eines Kopiervorgangs sondern des Einfrierens eines älteren Daten-Stands).
2. Replikation
Das Ist Streaming purwie eine Radiosendung ohne einen Vergleich von Daten wie z.B. bei rsync.
Bei einemi inkrementellen Replikation wird ein neuer Quellsnap erzeugt und als Different zu einem Basissnap übertragen. Das Zieldateisystem wird dazu vor dem Empfang auf den Basisstand rückgesetzt der identisch ist zum Basissnap des Quellsystems. Kann man sich vorstellen wie die Fortsetzung der Aufnahme eines Liedes im Radio das man teilweise aufgenommen hatte und das später an gleicher Stelle fortgesetzt wird. Vor der Aufnahme des restlichen Liedes spult man zurück zum Ende und nimmt dann den Rest auf. Im Ergebnis hat man das ganze Lied.
Eine Replikation ohne gemeinsamen Basissnap kann man daher nicht fortsetzen sondern muss erneut eine volle Erstübertragung starten. (Wenn man nicht zum Ende der letzten Teil-Übertragung des Liedes zurückspulen kann, ergibt die Fortsetzung der Sendung nicht mehr das komplette Lied)
1. Copy on Write
Wenn man in einer Textdatei Hans zu Haus ändert wurde bei älterene Dateisystemen nur die betroffene Information (also idealerweise 1 Byte) geändert. Sun wollte das bei ZFS nicht mehr so haben weil wenn beim Ändern der Datei ein Absturz erfolgt nachdem die Datei geändert wurde aber bevor die Metadaten auf den neuen Stand gebracht wurden war das Dateisystem kaputt (ok passierte eher bei Ändern von Hans zu Hänschen).
ZFS schreibt daher immer den betroffenen Datenblock (in recsize, z.B. 128k, variabel kleiner) neu. Ist das komplett erfolgreich, ist der neue Datenblock aktiv, ansonst der vorherige (kein korruptes Dateisystem per Design). Der alte Datenblock wird dann für weitere Nutzung freigegeben es sei denn man hat einen Snap gesetzt. Der friert dann den Datenblock ein. Daher wird ein ZFS Snap ja auch ohne Zeitverzug erstellt (ist nicht Ergebnis eines Kopiervorgangs sondern des Einfrierens eines älteren Daten-Stands).
2. Replikation
Das Ist Streaming purwie eine Radiosendung ohne einen Vergleich von Daten wie z.B. bei rsync.
Bei einemi inkrementellen Replikation wird ein neuer Quellsnap erzeugt und als Different zu einem Basissnap übertragen. Das Zieldateisystem wird dazu vor dem Empfang auf den Basisstand rückgesetzt der identisch ist zum Basissnap des Quellsystems. Kann man sich vorstellen wie die Fortsetzung der Aufnahme eines Liedes im Radio das man teilweise aufgenommen hatte und das später an gleicher Stelle fortgesetzt wird. Vor der Aufnahme des restlichen Liedes spult man zurück zum Ende und nimmt dann den Rest auf. Im Ergebnis hat man das ganze Lied.
Eine Replikation ohne gemeinsamen Basissnap kann man daher nicht fortsetzen sondern muss erneut eine volle Erstübertragung starten. (Wenn man nicht zum Ende der letzten Teil-Übertragung des Liedes zurückspulen kann, ergibt die Fortsetzung der Sendung nicht mehr das komplette Lied)
Zuletzt bearbeitet:
CommanderBond
Enthusiast
- Mitglied seit
- 16.04.2012
- Beiträge
- 703
Und was ist ein Basissnap`?
