[Sammelthread] ZFS Stammtisch

@TCM habe ich auch schon überlegt.
Meinnst es reicht wenn ich 1 oder mehrere festplatten aus dem server ausbaue und die mit dem hexeditor etwas bearbeite?
Ich probiere es.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ist das dein Ernst?

Aus Hipster - OpenIndiana - OpenIndiana Wiki :

"Before considering using "hipter", please read the statement below.
Unstable version

Even though, hipster might contain some newer packages it is generally not advised for installation, which need some level of stability such as servers or fully functioning desktop. Things might break and could cause system/service downtime. Do upgrade only if you know what you are doing. You have been warned!"
 
Ja ist es. 151a8 hat viel zu viele (bereits gefixte) Bugs. Warum sollte man sich damit noch rumärgern?
Wenn man ohne GUI arbeitet ist Hipster schon deutlich näher an Illumos dran und was dort eingecheckt wird, ist eigentlich schon sehr stabil.
Wenn man in ein neues BE installiert (Openindiana -> Hipster) kann man ja auch jederzeit wieder zurück, das wird bei Openindiana -> Omnios schon komplizierter.


cu
 
Kleine Info:

Ich habe mich mal wieder an eine Neuinstallation des ESXi gewagt, da ich in der Vergangenheit immer wieder Stabilitätsprobleme mit 5.5er Versionen hatte und noch auf 5.1 war. Bin jetzt auf 5.5.0 (Build 2456374) NFS ist jetzt stabil und sonst läuft die Kiste sehr gut, ich würde sogar sagen besser als meine alte 5.1er Installation. Leider habe ich mal wieder das Problem, dass der vmxnet3 nicht will, ich bekomme gar keinen Connect zur OmniOS VM damit vom ESXi, obwohl ich diesmal keine manuelle Nachinstallaton des Netzwerktreibers gemacht habe, um den zweiten NIC zu nutzen, an Problemen wegen anderem Treiber kann es also nicht liegen...

Ich gebe für die Zukunft auf mit meinem Board (Supermicro X9SCM-F) den vmxnet3 zu nutzen, entweder funktioniert er gar nicht oder nicht stabil. Bin das ja gewohnt und der E1000 liefert eigentlich auch genug Performance bei meiner Konfiguration.
 
Zuletzt bearbeitet:
@gea: Danke für das neue Feature ESXi hot-snaps, habs gerade getestet, funktioniert wunderbar bei mir :)

Allerdings gibt es wohl noch einen kleinen Bug: Wenn ich Request ESXi VM List aufrufe, dann verbindet er sich kurz mit dem Server und zeigt auch die VMs an. Allerdings zeigt er die Liste nach dem Aufruf nicht mehr im Fenster die VMs in der Tabellenform an, die Datei "/var/web-gui/_log/esxiserver.log" ist leer.

Daher kann man die Info nicht mehr in "edit ESXi VM List" weiter verarbeiten, musste dann schnell den Output markieren und kopieren und den Hostnamen ergänzen für die Job Liste.

Wenn ich mir was wünschen dürfte:

Es wäre schöner, wenn man die Liste gleich in der richtigen Form vom Server abrufen könnte und angezeigt bekommt, damit man sie einfach per Copy & Paste in die VM Liste übernehmen kann, ohne Änderungen noch machen zu müssen, wie Hostnamen einfügen. Damit lässt sich "import new actions..." viel einfacher nutzen, ohne noch viel zu editieren.

Danke!
 
Zuletzt bearbeitet:
automatenraum schrieb:
@gea: Danke für das neue Feature ESXi hot-snaps, habs gerade getestet, funktioniert wunderbar bei mir :)

Allerdings gibt es wohl noch einen kleinen Bug: Wenn ich Request ESXi VM List aufrufe, dann verbindet er sich kurz mit dem Server und zeigt auch die VMs an. Allerdings zeigt er die Liste nach dem Aufruf nicht mehr im Fenster die VMs in der Tabellenform an, die Datei "/var/web-gui/_log/esxiserver.log" ist leer.

Daher kann man die Info nicht mehr in "edit ESXi VM List" weiter verarbeiten, musste dann schnell den Output markieren und kopieren und den Hostnamen ergänzen für die Job Liste.

Wenn ich mir was wünschen dürfte:

Es wäre schöner, wenn man die Liste gleich in der richtigen Form vom Server abrufen könnte und angezeigt bekommt, damit man sie einfach per Copy & Paste in die VM Liste übernehmen kann, ohne Änderungen noch machen zu müssen, wie Hostnamen einfügen. Damit lässt sich "import new actions..." viel einfacher nutzen, ohne noch viel zu editieren.

Danke!
Zum Vergrößern anklicken....

Es sollte eigentlich schon funktionieren.
Ich muss aber bei Gelegenheit dafür sorgen, dass bei einem Wechsel der Editieroptionen ein Neuladen des entsprechenden Formulars erfolgt. Momentan muss man gezielt etwas anwählen und bestätigen.
Ich komme aber im Moment nicht dazu, da mir etwas die Zeit fehlt.

Siehe Menü Jobs >> ESXi hot-snaps >> help

Preparations:
- create SSH keys on this machine and upload the pub part of the key to your ESXi server (see menu Service-SSH-SSH keys)
- select a list of VMs for one or more ESXi servers where you want to create ESXi snaps prior the ZFS snap
- enable the "do ESXi snaps prior the ZFS snap" function as a job parameter
care about: All of the selected VMs are located on this ZFS filesystem shared to ESXi as an NFS datastore

- use menu ESXi hot-snaps >> ESXi serverlist and enter a list of ESXi server
- use menu ESXi hot-snaps >> request ESXi VM list to read in a list of VMs (click on submit on that menu)
- use menu ESXi hot-snaps >> edit ESXi VM to preselect VMs where you want to do snaps

- use menu ESXi hot-snaps, select a pre snapjob and import new actions to import a list of pre actions (prior ZFS snap)
- use menu ESXi hot-snaps, select a post snapjob and import new actions to import a list of post actions (after ZFS snap)

edit that lists if needed
- enable prejob in the autosnap-jobsettings (prejob=yes)
 
Ich habe die Hilfe schon fleissig studiert und befolgt, es geht ja auch alles bis auf die Liste, die wird bei mir nicht mehr angezeigt nach dem Laden vom Server. Aber egal das wird schon, es läuft jetzt und ich mache auch nicht permanent Änderungen...

Lass dir Zeit, wollte es dich nur wissen lassen.
 
automatenraum schrieb:
Änderungen...
Lass dir Zeit, wollte es dich nur wissen lassen.
Zum Vergrößern anklicken....

Momentan ist es der erste Ansatz, die Vorteile sicherer ESXi Hot-Snaps mit ZFS snaps und allen ZFS Optionen wie Replikation oder unbegrenzter Anzahl zu kombinieren. Die Umsetzung wird sicher noch besser werden.
 
So auf meinem HP ML310e Gen8 läuft jetzt endlich auch mal OmniOS + Nappit mit PCI Passtrough vom IBM M1015 unter ESXi 5.5u2 + aktuelle Patches.

Heute Abend mal die Platten einrichten und die ersten VMs anlegen und alles testen :)
 
Probleme mit ACLs

Ausgangssituation:

(1) ZFS-Filesystems:
dpool/share (sharesmb=name=share, aclinherit=passthrough, aclmode=passthrough)
dpool/share/user1 (properties inherited from dpool/share)
dpool/share/user2 (properties inherited from dpool/share)
dpool/share/public (properties inherited from dpool/share)

Alle Filesysteme wurden mit chmod auf 777 gesetzt.

(2) User:
„user1“ und „user2“ sind im System (der Gruppe „staff“ zugeordnet) angelegt.

(3) Zielvorstellung:
/dpool/share/public: Alle dürfen alles
/dpool/share/user1: user1 darf alles, user2 lesen und anlegen
/dpool/share/user2: user2 darf alles, user1 lesen und anlegen

(4) sharemgr show -vp
default nfs=()
smb smb=()
* /var/smb/cvol
c$=/var/smb/cvol smb=(abe="false" guestok="false") "Default Share"
zfs nfs=() smb=()
zfs/dpool/share smb=()
share=/dpool/share
share_public=/dpool/share/public
share_user1=/dpool/share/user1
share_user2=/dpool/share/user2

Wenn ich mich jetzt von einem Win 8.1 Pro als Administrator anmelde und das Netzlaufwerk dann mit abweichenden Anmeldeinformationen (als root-User des OmniOS) verbinde, sehe ich nach öffnen des Netzlaufwerks auch die drei Ordner public, user1 und user2.

Dann
(1) Rechtsklick auf Ordner "user1", "Eigenschaften" / "Sicherheit" / "Erweitert"
(2) "Erweiterte Sicherheitseinstellungen für (Ordner) user1", "Hinzufügen"
(3) Berechtigungseintrag für Ordner "user1", "Prinzipal auswählen"
(4) "Benutzer und Gruppen auswählen", "Erweitert", "Jetzt suchen"

Die User "user1" und "user2" werden hier auch angezeigt. Wenn ich dann einen auswähle und auf "Namen überprüfen" klicke kommt keine Fehlermeldung. Bis hierher alles wie erwartet.

Klicke ich dann aber auf "OK" um die Zuordnung vorzunehmen kommt die Meldung "Fehler bei der Suche nach anzuzeigenden Benutzernamen."

TestACL_Rechte_Fehlermeldung.JPG

Google spuckte zu dieser Fehlermeldung leider nichts brauchbares aus.

Hat jemand ne Idee, was die Ursache sein könnte?

EDIT: Tippfehler
 
Zuletzt bearbeitet:
Ich vermute das Problem liegt an:
Alle Filesysteme wurden mit chmod auf 777 gesetzt.
Zum Vergrößern anklicken....

Diese Anweisung löscht alle ACL inheritance Angaben, da traditionelle Permissions das nicht können.
Daher mit Solaris CIFS (ACL only) niemals Unix Permissions benutzen

Man müsste folgende ACL setzen:
share=/dpool/share
- alle dürfen Ordner und optional Dateien und Attribute auflisten z.B.
- Readx für everyone, aber nur diesen Ordner, ohne Vererbung

/dpool/share/public: Alle dürfen alles, d.h.
- Modify oder Full für everyone, mit Vererbung

/dpool/share/user1
- Modify oder Full für user1 mit Vererbung
- Readx und Create für user2 mit Vererbung

/dpool/share/user2
- Modify oder Full für user2 mit Vererbung
- Readx und Create für user1 mit Vererbung
 
Bei kritischen Daten ist die allgemeine Empfehlung wöchentlich bei Desktop Platten und monatlich bei Serverplatten.
Zum Vergrößern anklicken....
Die Empfehlung ist aber "dumm" weil dadurch Desktop Platten in der Regel schon außerhalb ihrer Spezifikation betrieben werden. Sprich ich erhöhe dadurch die Warscheinlichkeit dass sie mir ausfallen.

Wie gesagt die 3TB Platte von Seagate ist mit 55TB im Jahr angegeben. Die kannst du somit 18mal im Jahr scrubben und nicht 52mal.
 
Zuletzt bearbeitet:
CommanderBond schrieb:
Hat jemand schon die 8TB Festplatte von Seagate im Einsatz mit ZFS?

Die hat ja nur ne Workload von 180TB soweit ich weiß. Würde sich ja dann "beißen" mit der Empfehlung Consumer Platte jede Woche zu scrubben [...]

Bei meinen ST3000DM001 steht im Datenblatt 55TB. Da es ne 3TB Platte ist würde das bedeuten man könnte 18mal im Jahr scrubbing betreiben
Zum Vergrößern anklicken....

Was ist los?!

http://www.seagate.com/staticfiles/docs/pdf/datasheet/disc/barracuda-ds1737-1-1111us.pdf

Wo sieht man da 55TB? Seit wann haben mechanische Platten ein "Workload"-Limit?! Das ist ja ganz konfus.

Edit: Und bei den SMR-Platten dürfte sich "Workload" auf das Schreiben beziehen, da das der kritische Vorgang ist. Das Lesen dürfte mal herzlich egal sein.
 
Zuletzt bearbeitet:
Ist so ein scrub unbedingt nötig, oder einfach nice to have?

Ich habe oft alte server gesehen, die 10 oder 15 jahre mit nur eine festplatte durchliefen ohne irgendwelche Datenverluste o.Ä
 
TCM schrieb:
Was ist los?!

http://www.seagate.com/staticfiles/docs/pdf/datasheet/disc/barracuda-ds1737-1-1111us.pdf

Wo sieht man da 55TB? Seit wann haben mechanische Platten ein "Workload"-Limit?! Das ist ja ganz konfus.

Edit: Und bei den SMR-Platten dürfte sich "Workload" auf das Schreiben beziehen, da das der kritische Vorgang ist. Das Lesen dürfte mal herzlich egal sein.
Zum Vergrößern anklicken....


http://www.seagate.com/staticfiles/support/docs/manual/desktop/Barracuda 7200.14/100686584.pdf

Seite 12

Habe es bei mir nun deswegen umgestellt von wöchentlichem scrubbing auf monatliches. Ansonsten habe ich 156TB pro Jahr pro Platte mindestens. Das wäre mehr als das 3fache was Seagate empfiehlt.
 
Zuletzt bearbeitet:
VivianMeally schrieb:
Ist so ein scrub unbedingt nötig, oder einfach nice to have?

Ich habe oft alte server gesehen, die 10 oder 15 jahre mit nur eine festplatte durchliefen ohne irgendwelche Datenverluste o.Ä
Zum Vergrößern anklicken....

.. die ohne bekannt gewordene Datenverluste durchliefen!

Das Besondere an einem ZFS Scrubbing ist, dass es alle Datenblöcke einliest und auf Prüfsummenfehler testet. Die treten mit einer statistischen Wahrscheinlichkeit auf. Bei Platten mit hoher Dichte und Kapazität damit häufiger als auf kleinen Platten. Es arbeitet damit auch viel umfassender als ein chkdsk bei ntfs oder ext4. Es erkennt alle Datenfehler und repariert diese und das sogar im Online-Betrieb (Kein Dismount für einen Filcheck).

Bei alten Servern gibt es kein ZFS, damit keine Dateisystem-Prüfsummen und damit nicht mal den Hauch einer Möglichkeit diese Fehler zu entdecken. Zur Reparatur braucht ZFS dann aber Redundanz z.B. Copies=2 oder Raid.

Die Häufigkeit in der man ein Scrubbing durchführen sollte, hängt von der Qualität der Festplatten ab. Das Scrubbing dient ja nicht nur dazu einzelne Fehler zu reparieren sondern auch generelle Probleme frühzeitig zu erkennen damit die Platte getauscht werden kann. Bei kritischen Daten ist die allgemeine Empfehlung wöchentlich bei Desktop Platten und monatlich bei Serverplatten. Man kann das auch gut selber einschätzen, wenn man die Scrub-Ergebnisse kontrolliert. Wenn nur ganz selten Party Errors erkann werden, kann man das seltener machen. Wenn häufiger Parity Errors gefunden werden, vielleicht öfters. Dass überhaupt Paritity Errors gefunden werden, unterstreicht dann nochmal die Notwendigkeit von Dateisystemen mit voller Daten-Paritäts-Prüfung.
 
gea schrieb:
Ich vermute das Problem liegt an:

"Alle Filesysteme wurden mit chmod auf 777 gesetzt."

Diese Anweisung löscht alle ACL inheritance Angaben, da traditionelle Permissions das nicht können.
Daher mit Solaris CIFS (ACL only) niemals Unix Permissions benutzen
Zum Vergrößern anklicken....

Das Setzen auf 777 habe ich nur initial gemacht, also bevor ich irgendwelche ACLs gesetzt habe, welche die Unix-Permmissions ja dann nach Bedarf wieder entsprechend einschränken.

BTW: Sollte nicht sowieso besser aclmode=restricted gesetzt werden (siehe Illumos feature 3254 und zfs man-page) um Änderungen über /usr/gnu/bin/chmod zu verhindern?

gea schrieb:
Man müsste folgende ACL setzen:
share=/dpool/share
- alle dürfen Ordner und optional Dateien und Attribute auflisten z.B.
- Readx für everyone, aber nur diesen Ordner, ohne Vererbung

/dpool/share/public: Alle dürfen alles, d.h.
- Modify oder Full für everyone, mit Vererbung

/dpool/share/user1
- Modify oder Full für user1 mit Vererbung
- Readx und Create für user2 mit Vererbung

/dpool/share/user2
- Modify oder Full für user2 mit Vererbung
- Readx und Create für user1 mit Vererbung
Zum Vergrößern anklicken....

So in etwas habe ich mir das vorgestellt, ich konnte nur entgegen meiner Erwartung unter Windows 8.1 Pro keine User-Permissions (nur Triviale: Besitzer, Gruppe und Jeder) auf die o.a. Ordner setzen. "user1" und "user2" sind dort zwar sichtbar (als "192.168.174\user1" und "192.168.174\user2") und auswählbar, aber eben nicht zuordbar (dann kommt die Fehlermeldung aus meinem vorigen Post).

Wenn ich z.B. den User "user1" manuell unter Windows zuordnen möchte (indem ich "192.168.174.158\user1" direkt erfasse), kommt die folgende Fehlermeldung:
"Ein Objekt (Benutzer, Gruppe oder Integriertes Sicherheitsprinzipal) namens "192.168.174.158\user1" wurde nicht gefunden. (...)"
ACL_Fehlermeldung_user1_manuell.JPG

Ich kann die Rechte ja auch direkt per CLI zuordnen, war aber der Meinung, dass es eigentlich auch von Windows aus gehen müsste.

BTW: Es ist offensichtlich auch nicht möglich einen "Create" (add_file) zuzulassen, ohne dabei gleichzeitig auch "Modify" (write_data) zuzulassen:

Code: 
root@OmniOS-stable:/dpool# /usr/bin/ls -v
total 1
dr-xr-xr-x+  6 root     root           6 Feb 21 14:43 share
     0:everyone@:list_directory/read_data/add_subdirectory/append_data
         /read_xattr/write_xattr/execute/read_attributes/write_attributes
         /read_acl/synchronize:file_inherit/dir_inherit:allow

root@OmniOS-stable:/dpool# /usr/bin/chmod A0=everyone@:add_file/list_directory/read_data/add_subdirectory/append_data/read_xattr/write_xattr/execute/read_attributes/write_attributes/read_acl/synchronize:file_inherit/dir_inherit:allow share

root@OmniOS-stable:/dpool# /usr/bin/ls -v
total 1
drwxrwxrwx+  6 root     root           6 Feb 21 14:43 share
     0:everyone@:list_directory/read_data/add_file/write_data
         /add_subdirectory/append_data/read_xattr/write_xattr/execute
         /read_attributes/write_attributes/read_acl/synchronize
         :file_inherit/dir_inherit:allow

In dem unteren ACL-entry ist neben "add_file" auch "wirte_data" hinzu gekommen, obwohl der durchgeführte /usr/bin/chmod diesen nicht enthielt. Das nur so am Rande.
 
Zuletzt bearbeitet:
Bei kritischen Daten ist die allgemeine Empfehlung wöchentlich bei Desktop Platten und monatlich bei Serverplatten.
Zum Vergrößern anklicken....
Die Empfehlung ist aber "dumm" weil dadurch Desktop Platten in der Regel schon außerhalb ihrer Spezifikation betrieben werden. Sprich ich erhöhe dadurch die Warscheinlichkeit dass sie mir ausfallen.

Wie gesagt die 3TB Platte von Seagate ist mit 55TB im Jahr angegeben. Die kannst du somit 18mal im Jahr scrubben und nicht 52mal. Was bringt mir öfter scrubben wenn ich dadurch die Ausfallwarscheinlichkeit erhöhe?

Dann doch eher weniger oft scrubben und dafür ne Parityplatte mehr reinhängen um das ganze auszugleichen

Die Häufigkeit in der man ein Scrubbing durchführen sollte, hängt von der Qualität der Festplatten ab.
Zum Vergrößern anklicken....
"Gute" Serverfestplatten vertragen aber auch häufigeres scrubben besser als "schlechte" Consumerplatten. Da liegt doch grad der Hund begraben. Bei den Platten wo du es nicht so häufig brauchst könntest du es öfter machen, da wo du es häufiger machen solltest, solltest es aber grade nicht tun weil die Platte auf soviel Workload nicht ausgelegt ist.
 
Zuletzt bearbeitet:
zos schrieb:
BTW: Es ist offensichtlich auch nicht möglich einen "Create" (add_file) zuzulassen, ohne dabei gleichzeitig auch "Modify" (write_data) zuzulassen:
Zum Vergrößern anklicken....

Da File-Creator auch File-Owner ist, hat der eh Full-Permissions - es sei denn man verhindert das mit aclinherit = restricted.
Mit Win 8.1 Pro habe ich es nocht nicht versucht. Mehrere Windows Versionen haben aber Probleme, ACL remote zu setzen.

- - - Updated - - -

CommanderBond schrieb:
Die Empfehlung ist aber "dumm" weil dadurch Desktop Platten in der Regel schon außerhalb ihrer Spezifikation betrieben werden. Sprich ich erhöhe dadurch die Warscheinlichkeit dass sie mir ausfallen.

Wie gesagt die 3TB Platte von Seagate ist mit 55TB im Jahr angegeben. Die kannst du somit 18mal im Jahr scrubben und nicht 52mal. Was bringt mir öfter scrubben wenn ich dadurch die Ausfallwarscheinlichkeit erhöhe?

Dann doch eher weniger oft scrubben und dafür ne Parityplatte mehr reinhängen um das ganze auszugleichen


"Gute" Serverfestplatten vertragen aber auch häufigeres scrubben besser als "schlechte" Consumerplatten. Da liegt doch grad der Hund begraben. Bei den Platten wo du es nicht so häufig brauchst könntest du es öfter machen, da wo du es häufiger machen solltest, solltest es aber grade nicht tun weil die Platte auf soviel Workload nicht ausgelegt ist.
Zum Vergrößern anklicken....

Die Angabe von 55 TB/Jahr bezieht sich nur darauf, dass die angegebene MTBF bei dieser ganz geringen Nutzung gegeben ist. Bei einer 3 TB Platte sind das aber gerade mal ca 20 x Kapazität lesen.

Meine Empfehlung wäre aber eher: Finger weg von der 3 TB Seagate. Ich habe ein gutes Duzend davon in einer Backupmaschine und werde die wohl wegschmeissen da ich nur Probleme habe. Die 40% Ausfallrate pro Jahr bei Backplaze entspricht auch meiner Erfahrung.

http://techreport.com/news/27697/la...ity-data-shows-carnage-for-3tb-seagate-drives
 
gea schrieb:
Da File-Creator auch File-Owner ist, hat der eh Full-Permissions - es sei denn man verhindert das mit aclinherit = restricted.
Zum Vergrößern anklicken....

Da frage ich mich dann aber, warum es die Unterscheidung zwischen "add_file" und "write_data" überhaupt gibt. Denn grundsätzlich scheinen "add_file" und "write_data" immer das gleiche Flag ("w") zu setzen, so dass hier de facto kein Unterschied zu bestehen scheint. In der Oracle Doku steht hierzu unter "Table 8-2 ACL Access Privileges":

Access Privilege: add_file
Compact Access Privilege: w
Description: Permission to add a new file to a directory.

Access Privilege: write_data
Compact Access Privilege: w
Permission to modify or replace the contents of a file.

gea schrieb:
Mit Win 8.1 Pro habe ich es nocht nicht versucht. Mehrere Windows Versionen haben aber Probleme, ACL remote zu setzen.
Zum Vergrößern anklicken....
OK, danke für den Hinweis, ich dachte bei den neueren Windows-Pro-Versionen würde das immer gehen.
 
zos schrieb:
Da frage ich mich dann aber, warum es die Unterscheidung zwischen "add_file" und "write_data" überhaupt gibt. Denn grundsätzlich scheinen "add_file" und "write_data" immer das gleiche Flag ("w") zu setzen, so dass hier de facto kein Unterschied zu bestehen scheint
Zum Vergrößern anklicken....

NFS4/ Windows ntfs ACL erlauben extrem feine Rechtevergaben.
Ich muss auch immer wieder überlegen, was/wie funktioniert.

In diesem Fall wird es wohl so sein, dass damit ein unterschiedliches Verhalten entsteht, je nachdem ob es auf eine Datei oder einen Ordner angewendet wird.
 
Ich hatte heute einen Absturz meiner Nas4Free VM, Grund war eine Überlastung des Hosts. Nach dem Reboot der ganzen Kiste und Neustart von Nas4Free zeigt mir "zpool status" einen CKSUM Fehler auf beiden Platten des Mirrors, schreibt aber gleichzeitig "Applications are unaffected". Wie ist denn das jetzt genau zu verstehen? Wenn eine Platte einen Fehler hätte, dann hätte er ja von der anderen korrigieren können, aber so? Oder trat durch den Crash zufällig auf jeder Platte an unterschiedlicher Stelle ein Fehler auf? Ich blick das gerade nicht so ganz.

Code: 
[FONT=Courier New]
pool: raid1-hd
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.  An
	attempt was made to correct the error.  Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
	using 'zpool clear' or replace the device with 'zpool replace'.
   see: [url=http://illumos.org/msg/ZFS-8000-9P]ZFS-8000-9P[/url]
  scan: scrub repaired 0 in 10h19m with 0 errors on Sun Feb 15 11:19:04 2015
config:

	NAME        STATE     READ WRITE CKSUM
	raid1-hd    ONLINE       0     0     0
	  mirror-0  ONLINE       0     0     1
	    ada2    ONLINE       0     0     1
	    ada3    ONLINE       0     0     1

errors: No known data errors
[/FONT]


Kleines Update, jetzt wird es gerade irgendwie komisch:

Code: 
[FONT=Courier New]
  pool: raid1-hd
 state: ONLINE
status: One or more devices has experienced an error resulting in data
	corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
	entire pool from backup.
   see: http://illumos.org/msg/ZFS-8000-8A
  scan: scrub repaired 0 in 10h19m with 0 errors on Sun Feb 15 11:19:04 2015
config:

	NAME        STATE     READ WRITE CKSUM
	raid1-hd    ONLINE       0     0   300
	  mirror-0  ONLINE       0     0   601
	    ada2    ONLINE       0     0   601
	    ada3    ONLINE       0     0   601

errors: Permanent errors have been detected in the following files:

        raid1-hd/backup:<0x100d>
[/FONT]


Nach einem Reboot sind die Checksum Fehler zwar weg, aber der Rest bleibt:


Code: 
[FONT=Courier New]
  pool: raid1-hd
 state: ONLINE
status: One or more devices has experienced an error resulting in data
	corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
	entire pool from backup.
   see: http://illumos.org/msg/ZFS-8000-8A
  scan: scrub repaired 0 in 10h19m with 0 errors on Sun Feb 15 11:19:04 2015
config:

	NAME        STATE     READ WRITE CKSUM
	raid1-hd    ONLINE       0     0     0
	  mirror-0  ONLINE       0     0     0
	    ada2    ONLINE       0     0     0
	    ada3    ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:

        raid1-hd/backup:<0x100d>
[/FONT]


Aber was soll "raid1-hd/backup:<0x100d>" bedeuten, die Datei gibts gar nicht?
 
Zuletzt bearbeitet:
trendco schrieb:
...

Aber was soll "raid1-hd/backup:<0x100d>" bedeuten, die Datei gibts gar nicht?
Zum Vergrößern anklicken....

Das sind Metadaten, kann alles mögliche sein. Den Fehler wirst du wahrscheinlich nicht mehr wegbekommen, versuch mal ein
zpool clear raid1-hd
Sonst würde ich per
zfs send raid1-hd/backup@snapshot |zfs recv raid1-hd/backup-new
sichern, dann
zfs destroy raid1-hd/backup
und
zfs rename raid1-hd/backup-new raid1-hd/backup
machen.

Du bist sicher das deine Platten bzw. der Controller in Ordnung sind? Absturz wg. Überlastung des Hosts? Gefällt mir nicht ...


cu
 
Soll ich denn mal einen SCRUB anschmeißen? Ich trau mich momentan gar nicht.
Und vor allem, woher weiss ich jetzt, ob und was genau von meinen Daten was abbekommen hat oder nicht?
 
Ich denke nicht das deine Daten betroffen sind. Ein Scrub kann jedenfalls nix schaden.
Was sind das denn für Platten?

cu
 
trendco schrieb:
Aber was soll "raid1-hd/backup:<0x100d>" bedeuten, die Datei gibts gar nicht?
Zum Vergrößern anklicken....

Das bedeuted, dass ein Checksumfehler in der Datei mit dieser Inode festgestellt wurde.
Da die Datei vermutlich gelöscht wurde, ist nur noch die Inode, nicht mehr der usrprüngliche Name verfügbar.

Um die Meldung wegzubekommen kann man folgendes versuchen
- zpool clear
- erneutes scrubbing
- pool export + import

Insgesamt ist das aber völlig belanglos.
Wichtiger ist die Frage woher die vielen Fehler plötzlich kommen, z.B: RAM/Power/Kabelprobleme etc
 
Zuletzt bearbeitet:
ludwinator: Die Platten sind 2x "Hitachi HDS5C3030ALA630"

Aber wie schon erwähnt, ich denke es liegt an dem Absturtz. Seit dem letzten Proxmox Update auf 3.4 hab ich einen (inzwischen) reproduzierbaren Fehler an meinem Host-System: Sobald der RAM mit gestarteten VM's überbelegt wird, verlangsamt sich der Host mit abschliessendem Crash. Bis ich das rausgefunden hatte, musste ich das System einige male hart abschalten, was aber bisher auch nie ein Problem war für ZFS. Eine Lösung für das Problem habe ich leider noch nicht, bin noch am testen.

gea: Das Seltsame ist nur, dass ich unter ""raid1-hd/backup" eigentlich gar nix gemacht hatte, geschweigedenn Dateien gelöscht. Ausser natürlich, dass zu dem Zeitpunkt mein MAC auf die Time-Machine gesichert hätte, die liegt auf ""raid1-hd/backup", aber da wird meines wissens doch nix gelöscht dabei!? RAM ist übrigens ECC.

Es läuft auch noch ein zweiter Mirror-Pool auf dem System mit 2x 840'er SSD's auf dem die VM's liegen, der hatte bisher keine Fehler gezeigt. Ich werde dann wohl mal einen SCRUB anschmeissen müssen und hoffen.
 
CommanderBond schrieb:
http://www.seagate.com/staticfiles/support/docs/manual/desktop/Barracuda 7200.14/100686584.pdf

Seite 12

Habe es bei mir nun deswegen umgestellt von wöchentlichem scrubbing auf monatliches. Ansonsten habe ich 156TB pro Jahr pro Platte mindestens. Das wäre mehr als das 3fache was Seagate empfiehlt.
Zum Vergrößern anklicken....

Also ich wusste ja, dass Seagate mittlerweile irgendwie absoluter Ramsch ist, aber solche Hütchenspielertricks setzen dem ja noch die Krone auf. Unkaufbar.
 
SCRUB ist durch, keine Fehler gefunden auf beiden Pools :banana:

Allerdings wird der Fehler immer noch angezeigt. Nach dem SCRUB hab ich noch ein "zpool clear raid1-hd" ausgeführt -> Fehler bleibt, dann noch den Pool exportiert/importiert -> Fehler bleibt. Nun hab ich noch mal ein SCRUB angestossen, mal schauen.

Was mir aber immer noch nicht klar ist, wie dieses Szenario zustande kommt. Snapshots hab ich auf dem betreffenden Datasets keine, gelöscht hab ich auch nix. Wie kann denn so etwas dann zustande kommen?
 
Anmelden, um zu antworten.

Ähnliche Themen

G
Wieviel ZFS steckt in Qnap ZFS ??
Antworten
5
Aufrufe
895
gea
G
Shihatsu
ZFS Pool "verschicken"
Antworten
9
Aufrufe
607
sandreas
S
thor17
Ceph Node auf bestehenden ZFS Pools
Antworten
3
Aufrufe
540
gea
G
G
[Übersicht] napp-it cs, Web-GUI für fast jeden ZFS Server oder Servergruppen
4 5 6
Antworten
158
Aufrufe
9K
gea
G
AliManali
*erledigt* Perc H310 flashen
Antworten
2
Aufrufe
314
AliManali
AliManali
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