[Sammelthread] ZFS Stammtisch

Von Weg habe ich nichts gelesen.

Ich seh das so
TrueNAS/FreeNAS ist ein NAS Web-Management Tool das auf Free-BSD aufbaut. Aktuell hinkt Free-BSD der Open-ZFS Entwicklung 1 Jahr hinterher. Damit sind Killer Features wie u.A. Verschlüssellung oder special vdev nicht enthalten.

Hintergrund
Bis vor ca 1 Jahr hat Free-BSD selber seinen Open-ZFS Zweig gepflegt und neue Features von Illumos übernommen. Aktuell finden jedoch neue Entwicklungen in Open-ZFS direkt statt. Illumos (das ist ja nicht nur ZFS sondern ein komplettes Unix als Fork von Solaris mit allen Serverdiensten wie Kernel SMB und NFS, iSCSI etc) pflegt im Wesentlichen nur noch das OS und Serverdienste wie SMB und entwickelt mit oder übernimmt neue ZFS Features aus dem zentralen Open-ZFS Repository. Diese Entwicklung ist letzlich der großen ZFS Entwicklergemeinde die aus dem Linux Bereich kommt geschuldet.

Free-BSD hat sich entschieden, seinen eigenen ZFS Zweig aufzugeben um direkt Open-ZFS zusammen mit Linux zu nutzen. Das Open-ZFS Repository ist damit gemeinsame Basis für ZFS auf Free-BSD und Linux und de Fakto Upstream von Illumos was Open-ZFS Features angeht, https://linuxnews.de/2019/11/openzfs-buendelt-die-zfs-entwicklung/

Diese Schwenk von Free-BSD ist noch nicht abgeschlossen. Wenn das der Fall istr, werden die Feutures von Linux und Free-BSD wieder identisch sein. Illumos hat die vor einem Jahr bereits übernommen.

Dieses Manko von Free-BSD ist wohl einer der Gründe für TrueNAS auch Linux zu unterstützen. Wichtiger ist jedoch dass die Grundfunktionen ZFS und SAMBA identisch sind. Eine Linuxversion damit ist quasi sofort lauffähig. Neu programmiert weren nur Systemkonfiguration und Extra Dienste und Virtualisierung. Ich habe ja auch eine Linux Version. Die ZFS Funktionen sind identisch zu der Solarish Version.

Ich gehe davon aus dass Linux zunächst ein zweites Standbein ist. Langfristig wird TrueNAS aber eher auf Linux schwenken da das Alleinstellungsmerkmal von Free-BSD vs Linux halt ZFS als Dateisystem war. Ist nicht so wie bei Solarish wo die OS Integration erheblich tiefer geht und ZFS mehr ist als nur Dateisystem
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Welches freie OS hat denn momentan die beste ZFS-Integration, die auf Illumos basierenden? Mit OpenIndiana habe ich schon ein bisschen rumgespielt.
 
Die möglichen Distributionen sind: https://illumos.org/docs/about/distro/

Die wichtigsten:
- OmniOS
Das ist die Distribution für Storage Server use. OmniOS ist extrem minimalistisch daher ultastabil, enthält aber alles was man für einen professionellen Storageserver haben möchte. Alleinstellungsmerkmal ist die Stable alle 6 Monate und eine Long Term Stable alle 3 Jahre. Dazu sehr zuverlässig Security Fixes (wenn nötig mehrfach im Monat). Die Bloody enthält dann wie OI das aktuelle Illumos damit neue Features in der nächsten Stable landen. Dazu enthält OmniOS die Virtualisierungsmöglichkeiten von SmartOS (neben KVM sind das LX/Linux Zonen und Bhyve als allgemeiner Virtualisierer). Darüberhinaus bietet OmniOS auf Wunsch kommerziellen Support. Auch ist es die "europäische Option". Die wichtigsten Firmen hinter OmniOS CE sitzen in der Schweiz und UK, https://omniosce.org/

- OpenIndiana.
Das ist quasi Illumos pur mit einem gut gepflegten Repository für Server und Desktop Apps. Vor allem wenn man einen universellen Homeserver mit einem grafischen Desktop möchte die erste Wahl, https://www.openindiana.org/

-SmartOS (Joyent/Samsung)
Das ist der Virtualisierungspezialist. Vom Konzept vergleichbar zu Proxmox. Da SmartOS von einem readonly USB Stick startet und alles auf dem Pool und virtualisiert bearbeitet, ist es für einen Storageserver weniger geeignet. Ich unterstütze es im Gegensatz zu Solaris/OmniOS und OI daher aktuell auch nicht mit meiner napp-it Web-UI, https://wiki.smartos.org/


Von der Open-ZFS Integration gesehen sind alle identisch. Bei OpenIndiana sind neueste Features sofort dabei. Bei OmniOS und SmartOS in der nächsten stable. War ab und zu auch schon gut so. Wer immer das neueste hat ist der erste der Fehler findet.
 
Zuletzt bearbeitet:
Danke für die tollen Infos! OmniOS habe ich mir jetzt auch mal runtergeladen, ich werde damit und mit OI sowe deinem Napp-It erstmal in einer VM rumspielen, ehe ich entscheide, ob das für mich in Frage kommt. Wahrscheinlich ist ZFS für meinen Homeserver auch völlig übertrieben, ECC RAM habe ich auch keinen.
 
Wenn man keinen ECC Speicher hat, dann können RAM Fehler bei ZFS wie bei jedem anderen Dateisystem auch zu unentdeckten Dateifehlern führen. Man hat mit ZFS dennoch eine höhere Sicherheit durch die Prüfsummen und Copy on Write (crashsicheres Dateisystem) sowie Versionierung über Snaps als mit älteren Dateisystemen.
 
Ich würde davon ausgehen dass ein Restore per Windows vorherige Version eine Kopieraktion ist (übers Netz). Ein lokales zfs rollback dagegen quasi sofort lokal ausgeführt wird.
Alles klar.Solltest du mal das Snapshotmenü in Napp it aufbohren, fände ich es praktisch, wenn man dort wie im Sinne der Vorherigen Versionen aus WIndows aus einem Zielsnapshot nur bestimmte Dateien bzw Ordner wiederherstellen könnte.Stand heute geht ja nur der gesammte Snapshot, was ja für ein VM Store etwas unvorteilhaft ist.

So hätte man den Vorteil, dass es definitiv auf dem Store System ausgeführt wird.

Fals dass überhaupt so einfach möglich ist.
 
Also ich mach das bei größeren Dateimengen immer lokal per Putty und midnight commander.
 
Ich habe ein kleines Howto erstellt wie man einen (nappit) ZFS Filer zu einem S3 Cloudserver machen kann und wie man Dateien von/zu nappit und von/zu einem Cloudservice (S3, Google, Micrsosft etc) oder zwischen diesen Cloudservices backuppen/kopieren/syncronisieren kann.


update:
I habe Infos zum Konfigurieren von rclone für https, verschlüsselte Dateien und Amazon S3/minIO und Google Drive hinzugefügt
 
Zuletzt bearbeitet:
Hallo in die ZFS-Runde.
Ich bin relativer ZFS-Neuling und experimentiere seit einigen Tagen (ohne wichtige Daten, praktisch nur Testdaten).
Jetzt habe ich ein Problem, wobei es auch "nur" ein Verständnisproblem sein kann:

Wenn ich einen Pool exportiere mit
zpool export -f tank
dürfte der Pool "tank" ja eigentlich nicht mehr vorhanden sein, oder genauer ausgedrückt, dürfte der Befehl
zpool status tank
einen Fehler ausgeben oder sagen "no such pool" oder ähnliches. Oder verstehe ich das falsch?

Ich habe nämlich das Problem, daß bei mir der Export-Befehl überhaupt keine Wirkung zu haben scheint. Eine halbe Sekunde nach dem Befehl erscheint die Befehlszeile wieder und das war's. Keine Fehlermeldung - weshalb ich davon ausgehe, daß der Export funktioniert hat. Und so wie ich das Manual begreife, sollte der Pool damit aus dem System entfernt werden. Wenn ich aber
zpool status tank
aufrufe, ist der Pool aber immernoch vorhanden und online und auch auf die Testdaten kann ich zugreifen. Was läuft denn hier falsch?

Drauf gestoßen bin ich aufgrund ausbleibender Export-Fehlermeldung erst, weil ich beim Import eine Fehlermeldung erhalte, die darauf hinweist, daß der Name des Pools "tank" bereits vorhanden wäre. Erst dadurch bin ich auf das Problem aufmerksam geworden.

Hat jemand einen Tipp für mich? Gibt es eine Verbose-Funktion von zpool, die ich noch nicht kenne und die mir evtl. mehr Infos ausspuckt?
 
Ein Schuss ins Blaue: Bist Du als normaler User angemeldet? Mal mit "pfexec zpool ..." oder "sudo zpool ..." probiert bzw mit root-login?

PS: "verbose" geht mit "zpool status -v", wird Dir vermutlich aber auch nicht viel mehr verraten.
 
Ich bin als root angemeldet.
Leider werden bei der Funktion zpool export nur die Parameter -f und -a aktzeptiert. -v (was ja in sehr vielen Befehlen als verbose-Parameter funktioniert) gibt es hier leider nicht. Und bei status bringt der Parameter auch nicht mehr informationen, wie du schon richtig vermutet hast.
 
Schon seltsam.
Ich hätte zunächst auch vermutet, dass man keine Root Rechte hat. Es gibt zwar Situationen wo ein Export nicht funktioniert, z.B. wenn man ein aktives Comstar iSCSI Target hat. Dann kommt aber ein Hinweis auf "Pool busy".

Auch ein Pool bei dem plötzlich mehr Platten ausfallen als es die Redundanz erlaubt, kann man nicht exportieren. Da kommt aber der Hinweis "pending i/o" also wartende Schreiboperationen.

Ich würde mal die erste Computerregel bei Problemen versuchen: Neustart
 
Ist es eine eher schlechte Idee im Pool Mirrors aus unterschiedlichen Größen zu haben?
Konkret habe ich 2x 1,92TB und 2-4x 480GB PM883 SSD
 
Geht, nur wenn der kleinere mirror voll wird, landen alle weiteren Daten halt nur noch auf dem großen mirror und Du hast keinen stripe Vorteil mehr.
 
Ich habe im Napp It gesehen dass eine HDD ein Problem hat.
Unter Disk Info steht


c2t0d0_smart_188 4295032833

c2t0d0_smart_overview2 problem


Was sagen diese Zahlen aus ? Ist eine Seagate Ironwolf 12 TB.
 
Ich benötige nochmal eure Hilfe. Wie bereits geschrieben, ich nutze OmniOs.
Hab bereits Poole per zfs smb freigegeben. Nun soll aber nicht mehr ein Nutzer zugreifen sondern mehrere .
Das ganze wird per ACL gesteuert. Soweit verstanden.

Mein Vorhaben: Bestimmte Nutzer sollen nur Ordner A und nicht Ordner B & C sehen. Was ich bis jetzt im Netz gelesen haben ist das nicht möglich?
Oder hat jemand eine Lösung?


Du steuerst das über die Windows NTFS Berechtigungen.

 
Ich habe im Napp It gesehen dass eine HDD ein Problem hat.
Unter Disk Info steht


c2t0d0_smart_1884295032833

c2t0d0_smart_overview2problem


Was sagen diese Zahlen aus ? Ist eine Seagate Ironwolf 12 TB.
Smart Rohwerte von Seagate Platten sind bei einigen Attributen nicht leicht zu verstehen, da sie mitunter mehrere Werte repräsentieren und ein Wert ungleich 0 nicht unbedingt ein Fehler sein muss. Da machen die interpretierten Werte Current/Worst/Threshold meistens mehr Sinn.
In diesem Fall sollte man sich den HEX Wert ansehen 000100010001. Für dieses Attribut bedeutet das, dass es 1 Comand Timeout > 7.5 Sekunden gab. Wenn die Zahl nicht weiter wächst würde ich das nicht unbedingt als Problem einstufen.
 
Wenn eine Platte kaputt geht, braucht man keine Smartwerte. Wenn Sie ernste Probleme hat, dann ist ZFS viel zuverlässiger beim Anzeigen von Fehlern über die Daten-Prüfsummen.

Smartwerte sind protokollierte Ereignisse und das kann man nutzen um künftige Probleme vorhersehbarer zu machen. Smart 188 ist ein Timeout Fehler z.B. wegen einem defekten Sektor. Das kann ein paar Mal vorkommen und ist dann unkritisch. Tritt das gehäuft auf (z.B. mehr als 12 mal) ist das ein Indiz für künftige Probleme. Im professionellen Einsatz sollte man die Platte tauschen oder mit einem low level tool überprüfen.

Unter Disks > Smart sieht man die aktuellen Werte.
Mit einem Mausover über z.B. 188 sieht man auch ab wann napp-it Fehler als relevant ansieht.

z.B.
 
Zuletzt bearbeitet:
Um Nochmal auf das Thema ZFS Send Resume zurückzukommen, da hatte ich ja folgendes gefunden

You can use the -s option of zfs receive which will save a resumable token on the receiving side if the transfer fails. It depends if you are using netcat (nc) or SSH.
On the recv machine (netcat only):
nc -l <port> | zfs receive -s -v tank/dataset
On the send machine:
Start with the usually send:
zfs send -v snapshot | nc <host> <port>
zfs send -v snapshot | ssh ... zfs receive -s -v tank/dataset
If the transfer fails, go on the recv machine and type:
zfs get all tank/dataset
Get the receive_resume_token and go on the send machine:
zfs send -v -t <token> | nc <host> <port>
zfs send -v -t <token> | ssh ... zfs receive -s -v tank/dataset
Here you go :)
habe da gerade mal einen Test gemacht.
Pool_01/xxx receive_resume_token 1-e091adb22-c8-789c636064000310a500c4ec50360710e72765a526973030dc179103abc2904f4b2b4e2d01c904e9c3e4d990e4932a4b528b81b48366cedb8f7c98fa4bf2d34b335318188e74dc940d38fedcda02499e132c9f97989bcac010909f9fa35b9498995265a46ba05f515101e738e4e59743dc0f007f1f2080 -
Wer zum Geier hat sich denn den Schmarrn ausgedacht, das sind bummelig über 200 Stellen, und die soll man Fehlerfrei eingeben?????
 
Nö, da soll man eigentlich nicht eingeben, sondern im Fall des Falles per script auslesen und weiterverarbeiten.
Ansonsten ist cut and paste dein Freund.
 
zB mit syncoid funktioniert das zfs send resume wunderbar (nachdem man eine kleine Änderung im Skript gemacht hat).
 
Kurze Frage: Ich habe mein Napp-It neu aufgesetzt: Zweite VM erstellt, Napp-It Installation, Pool von der alten VM importiert, Napp-It Einstellungen (var/web-gui/_log/) von der alten VM in Archiv gepackt, auf die neue VM kopiert und dort ausgepackt. Grundlegende Einstellungen sind übernommen worden, der Pool sieht soweit auch gut aus. Aber: die ganzen Accounts fehlten. Also Accounts aus /etc/passwd, /etc/shadow und Gruppen /etc/groups rüber kopiert. Damit sind die Accounts aber noch nicht unter SMB verfügbar. Was muss noch rüber kopiert werden, damit die ganzen Berechtigungen wieder wie vorhher funktionieren?
Danke vorab!
 
Windows nutzt ein anderes Passwortformat als Unix. Daher werden die Windows Passworte extra in /var/smb gespeichert. Auch nutzt der Solarish SMB Server nicht die Unix Gruppen in /etc/groups sondern stellt im Gegensatz zu z.B. SAMBA extra eine Windows kompatible lokale Gruppenverwaltung bereit. Die Datenbank dazu (smbgroup.db) liegt auch in /var/smb
 
Danke, @gea! Ist das SMB-Unix ID-Mapping auch dort irgendwo zu finden?
 
Der Solarish SMB Server braucht kein Mapping da er unmittelbar mit Windows SID und Windows Gruppen arbeitet. In Zusammenhang mit AD kann man aber AD User/Gruppen auf lokale Unix User/Gruppen mappen. Auch kann man lokale SMB Gruppen auf lokale Unix Gruppen mappen. Das braucht man aber nur z.B. wenn man SMB und z.B. NFS4 rechtemäßig syncron halten will. Der Befehl dazu ist idmap

idmap list zeigt aktuelle Zuordnungen
man idmap die Optionen.

 
Nochmals Danke! So ganz hatte das immer noch nicht funktioniert, aber ich habe jetzt noch ein paar andere Konfigurationen von Hand nachgezogen (Bonjour aktiviert, ein paar Unterschiede in der SMB Konfiguration. Ich war tatsächlich davon ausgegangen, dass die nötigen Konfigurationen in /var/web-gui/_log/ enthalten sind. Gibt es dazu irgendwo eine Doku, welche Konfigruationsdateien man von einer alten Napp-It VM mit rüber ziehen muss, wenn man Napp-It neu aufsetzen muss?
 
Das sind einfach drei Optionen

1. napp-it Settings
wie napp-it Passworte, Jobs, Gruppen, Appliance Maps etc. Ein Wiederherstellen von /var/web-gui/_log/* stellt das wieder her

2. Ein Backup Job (Jobs > Backup > Create)
sichert das und User, Gruppen, idmappings, Cluster Setting oder iSCSI/Comstar komplett auf den Datenpool. Da kann man nachschauen oder in napp-it Pro dies über User > Restore oder Comstar > Restore wiederherstellen.

Viele System und sonstige Service Einstellungen werden damit aber nicht gesichert. Will man das alles z.B. nach einem Ausfall der Systemplatte exakt wiederherstellen braucht man ein Disaster Recovery Verfahren.

3. Recovery
Dazu legt man einen Replikationsjob an und repliziert das aktive Bootenvironment auf den Datenpool. Napp-it bietet das als Replikations-Source direkt an. Den Job kann man dann z.B. täglich laufen lassen um immer ein aktuelles Backup zu haben.

Stirbt die Systemplatte oder möchte man das System auf einer größeren Platte wiederherstellen, so installiert man eine Minimalversion des Systems z.B. OmniOS + napp-it neu und stellt über einen Replikationsjob das alte Bootenvironment in rpool/ROOT wieder her. Dann aktiviert man das BE, bootet neu und hat exakt den alten Systemstand.
 
Danke, um das Thema kann ich mich leider erst später wieder kümmern, denn es hat sich ein weiterer Fehler eingeschlichen. Wäre ja auch zu schön, wenn man mal ein Thema konzentriert am Stück zuende bringen könnte... :rolleyes2:

Zu meinen vier im System befindlichen Platten wollte ich eine weitere hinzufügen, um dort ein Backup (zfs send|recv) anzulegen. Das Gehäuse ist hot swap fähig, das Board auch (ist im Bios auch eingeschaltet), also Platte in Einbaurahmen und eingeschoben. Die Platte wurde zwar "registriert" aber nicht eingebunden. Okay, dann Neustart. Also alle VMs runter gefahren, die Napp-It VM zuletzt. ESXi runtergefahren und Server komplett neu gestartet. Nach ESXi Neustart die Napp-It VM wieder gestartet. Keine Platten da. also gar keine bis auf die Systemplatte. Runter gefahren, alte Napp-It VM gestartet (Controller dort zuvor per pass through eingebunden). Platten erkannt, Pool nicht eingebunden, da Features (Encryption) in der alten VM nicht unterstützt werden. Aber grundsätzlich erkannt. Gut, nix kaputt. Wieder runter gefahren, neue Napp-It VM gestartet. Da gleiches Bild wie vorher. Keine Platten erkannt. Zum SATA Controller auch kein Hinweis.

fmadm faulty bringt folgenden Output, der erste Fehler wird der grundsätzliche Fehler, die anderen vermutlich Folgefehler (kein Controller, keine Platten, Pool fehlerhaft).

Was ist da los? Unter dem angegebenen Link finde ich leider auch keine weiterführenden Infos...

Danke und Gruß

Kandamir

PS: Die neu hinzugekommene Platte habe ich zwischenzeitlich auch wieder raus genommen - keine Änderung.

Code:
root@san:~# fmadm faulty
--------------- ------------------------------------  -------------- ---------
TIME            EVENT-ID                              MSG-ID         SEVERITY
--------------- ------------------------------------  -------------- ---------
Juni 27 08:39:11 d42df2bc-64c3-c0d1-be0c-944b13b38976  PCIEX-8000-0A  Critical

Host        : san
Platform    : VMware-Virtual-Platform   Chassis_id  : VMware-56-4d-55-ab-a2-24-0f-38-c2-bf-27-1f-c5-89-f0-70
Product_sn  :

Fault class : fault.io.pciex.device-interr
Affects     : dev:////pci@0,0/pci15ad,7a0@16/pci15d9,884@0
                  faulted and taken out of service
FRU         : "MB" (hc://:product-id=VMware-Virtual-Platform:server-id=san:chassis-id=VMware-56-4d-55-ab-a2-24-0f-38-c2-bf-27-1f-c5-89-f0-70/motherboard=0)
                  faulty

Description : A problem was detected for a PCIEX device.
              Refer to http://illumos.org/msg/PCIEX-8000-0A for more
              information.

Response    : One or more device instances may be disabled

Impact      : Loss of services provided by the device instances associated with
              this fault

Action      : Schedule a repair procedure to replace the affected device.  Use
              fmadm faulty to identify the device or contact your illumos
              distribution team for support.

--------------- ------------------------------------  -------------- ---------
TIME            EVENT-ID                              MSG-ID         SEVERITY
--------------- ------------------------------------  -------------- ---------
Juni 27 08:39:41 1c80bd3e-1f23-cbd2-be1e-c7941d6e8d9f  ZFS-8000-D3    Major  

Host        : san
Platform    : VMware-Virtual-Platform   Chassis_id  : VMware-56-4d-55-ab-a2-24-0f-38-c2-bf-27-1f-c5-89-f0-70
Product_sn  :

Fault class : fault.fs.zfs.device
Affects     : zfs://pool=Data/vdev=505a5e0f46e49225
                  faulted and taken out of service
Problem in  : zfs://pool=Data/vdev=505a5e0f46e49225
                  faulted and taken out of service

Description : A ZFS device failed.  Refer to http://illumos.org/msg/ZFS-8000-D3
              for more information.

Response    : No automated response will occur.

Impact      : Fault tolerance of the pool may be compromised.

Action      : Run 'zpool status -x' and replace the bad device.

--------------- ------------------------------------  -------------- ---------
TIME            EVENT-ID                              MSG-ID         SEVERITY
--------------- ------------------------------------  -------------- ---------
Juni 27 08:39:40 72edc8ba-2fb8-65de-d2d9-b77ab725783e  ZFS-8000-D3    Major  

Host        : san
Platform    : VMware-Virtual-Platform   Chassis_id  : VMware-56-4d-55-ab-a2-24-0f-38-c2-bf-27-1f-c5-89-f0-70
Product_sn  :

Fault class : fault.fs.zfs.device
Affects     : zfs://pool=Data/vdev=db88fd9b4535deeb
                  faulted and taken out of service
Problem in  : zfs://pool=Data/vdev=db88fd9b4535deeb
                  faulted and taken out of service

Description : A ZFS device failed.  Refer to http://illumos.org/msg/ZFS-8000-D3
              for more information.

Response    : No automated response will occur.

Impact      : Fault tolerance of the pool may be compromised.

Action      : Run 'zpool status -x' and replace the bad device.

--------------- ------------------------------------  -------------- ---------
TIME            EVENT-ID                              MSG-ID         SEVERITY
--------------- ------------------------------------  -------------- ---------
Juni 27 08:39:40 19aa42ac-fde4-cabe-8986-bace24a36836  ZFS-8000-D3    Major  

Host        : san
Platform    : VMware-Virtual-Platform   Chassis_id  : VMware-56-4d-55-ab-a2-24-0f-38-c2-bf-27-1f-c5-89-f0-70
Product_sn  :

Fault class : fault.fs.zfs.device
Affects     : zfs://pool=Data/vdev=48fc6b3ec91d52ca
                  faulted and taken out of service
Problem in  : zfs://pool=Data/vdev=48fc6b3ec91d52ca
                  faulted and taken out of service

Description : A ZFS device failed.  Refer to http://illumos.org/msg/ZFS-8000-D3
              for more information.

Response    : No automated response will occur.

Impact      : Fault tolerance of the pool may be compromised.

Action      : Run 'zpool status -x' and replace the bad device.

--------------- ------------------------------------  -------------- ---------
TIME            EVENT-ID                              MSG-ID         SEVERITY
--------------- ------------------------------------  -------------- ---------
Juni 27 08:39:41 46246322-e872-4ac8-aecb-afb8602e2454  ZFS-8000-CS    Major  

Host        : san
Platform    : VMware-Virtual-Platform   Chassis_id  : VMware-56-4d-55-ab-a2-24-0f-38-c2-bf-27-1f-c5-89-f0-70
Product_sn  :

Fault class : fault.fs.zfs.pool
Affects     : zfs://pool=Data
                  faulted and taken out of service
Problem in  : zfs://pool=Data
                  faulted and taken out of service

Description : A ZFS pool failed to open.  Refer to
              http://illumos.org/msg/ZFS-8000-CS for more information.

Response    : No automated response will occur.

Impact      : The pool data is unavailable

Action      : Run 'zpool status -x' and attach any missing devices, follow
              any provided recovery instructions or restore from backup.

--------------- ------------------------------------  -------------- ---------
TIME            EVENT-ID                              MSG-ID         SEVERITY
--------------- ------------------------------------  -------------- ---------
Juni 27 08:39:41 256fe8ab-a122-c790-b959-f24eadca8f75  ZFS-8000-D3    Major  

Host        : san
Platform    : VMware-Virtual-Platform   Chassis_id  : VMware-56-4d-55-ab-a2-24-0f-38-c2-bf-27-1f-c5-89-f0-70
Product_sn  :

Fault class : fault.fs.zfs.device
Affects     : zfs://pool=Data/vdev=7692ba5b81bf4c37
                  faulted and taken out of service
Problem in  : zfs://pool=Data/vdev=7692ba5b81bf4c37
                  faulted and taken out of service

Description : A ZFS device failed.  Refer to http://illumos.org/msg/ZFS-8000-D3
              for more information.

Response    : No automated response will occur.

Impact      : Fault tolerance of the pool may be compromised.

Action      : Run 'zpool status -x' and replace the bad device.
Beitrag automatisch zusammengeführt:

Okay, ich konnte es doch selbst regeln. Ich habe doch noch einen Hinweis bekommen, was zu tun ist:

fmadm repaired dev:////pci@0,0/pci15ad,7a0@16/pci15d9,884@0

Anschließend war der ZFS Pool noch kurz fehlerhaft, aber nach einem zpool status -x hatte sich auch das erledigt. Ich bin froh, dass das nun wieder läuft, richtig intuitiv ging das mit der Fehlersuche aber nicht. Naja, Hauptsache, es läuft wieder. Und danke für's Aushalten meiner Selbstgespräche... :LOL:
 
Zuletzt bearbeitet:
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