Stimmt die Groß- und Kleinschreibung und das Leerzeichen zwischen Tank und 1? Dann das ganze in Anführungszeichen setzen. (Deshalb verwende ich in Datei- und Ordnernamen nie Leerzeichen, sondern Unterstriche)
Zuletzt bearbeitet:
Ich würde erst mal den Stand abfragen
zpool get all Tank1 (kann in napp-it im cmd Fenster eingegeben werden)
Wenn autoexpand=off, dann aktivieren
z.B. in napp-it Menü Pool, beim Pool auf EXP klicken
Ansonsten sollte die höhere Kapazität nach dem Ersetzen der letzten Platte eines vdevs zur Verfügung stehen.
zpool get all Tank1 (kann in napp-it im cmd Fenster eingegeben werden)
Wenn autoexpand=off, dann aktivieren
z.B. in napp-it Menü Pool, beim Pool auf EXP klicken
Ansonsten sollte die höhere Kapazität nach dem Ersetzen der letzten Platte eines vdevs zur Verfügung stehen.
oc_parts
Enthusiast
- Mitglied seit
- 26.03.2006
- Beiträge
- 2.741
Danke allen für die Hilfe.
Werd ich heute abend direkt mal testen.
@Gea
Ich weiss nicht ob du es gelesen hast, aber gibt es die Option über Napp it den Rechner herunter zufahren bzw ein Filsystem von einem vdev auf das andere kopieren?
Oder muss ich das immer per ssh o.ä. machen?
Werd ich heute abend direkt mal testen.
@Gea
Ich weiss nicht ob du es gelesen hast, aber gibt es die Option über Napp it den Rechner herunter zufahren bzw ein Filsystem von einem vdev auf das andere kopieren?
Oder muss ich das immer per ssh o.ä. machen?
Zuletzt bearbeitet:
Wenn man den Thread so liest:
...trifft diese Aussage wohl ganz gut zu:
Das stimmt mich nun mehr als nachdenklich in Bezug auf mein System, zu mal ich auch jedes WE einen Scrup laufen lasse.
D.h. wenn ich einen RAM-Fehler habe und das System aber nicht abstürtzt und weiter läuft (ich also nix merke), werden beim nächsten SCRUB mit ziehmlicher Sicherheit meine kompletten Daten geschreddert.
Aber was ist eigentlich, wenn das Board einen defekt hat, oder die CPU? Können da auch solche schleichenden Fehler einen Totalausfall verursachen?
...trifft diese Aussage wohl ganz gut zu:
Das stimmt mich nun mehr als nachdenklich in Bezug auf mein System, zu mal ich auch jedes WE einen Scrup laufen lasse.
D.h. wenn ich einen RAM-Fehler habe und das System aber nicht abstürtzt und weiter läuft (ich also nix merke), werden beim nächsten SCRUB mit ziehmlicher Sicherheit meine kompletten Daten geschreddert.
Aber was ist eigentlich, wenn das Board einen defekt hat, oder die CPU? Können da auch solche schleichenden Fehler einen Totalausfall verursachen?
Zuletzt bearbeitet:
Der Link funktioniert nicht,
müsste dieser hier sein oder?
https://forums.freenas.org/index.php?threads/ecc-vs-non-ecc-ram-and-zfs.15449/
müsste dieser hier sein oder?
https://forums.freenas.org/index.php?threads/ecc-vs-non-ecc-ram-and-zfs.15449/
Der o a. FreeNAS-Thread wurde auch in der Google-Group "zfs-macos" kontrovers diskutiert (ist nicht wirklich OS X spezifisch). Es finden sich dort auch weitere interessante Links zum Thema. Am Ende wird gar die Integrität von x86-CPUs in Frage gestellt...
Es gibt folgende Möglichkeiten mit napp-it
- cmd: init 5
- job: init 5 abends um 22:00 Uhr
- Menü System - Shutdown
Ein Filesystem kann man nicht von einem vdev auf ein anderes Kopieren, nur von Pool zu Pool,
entweder mit napp-it und der Replication Extension oder manuell per CLI und zfs send
- - - Updated - - -
Das stimmt mich nun mehr als nachdenklich in Bezug auf mein System, zu mal ich auch jedes WE einen Scrup laufen lasse.
D.h. wenn ich einen RAM-Fehler habe und das System aber nicht abstürtzt und weiter läuft (ich also nix merke), werden beim nächsten SCRUB mit ziehmlicher Sicherheit meine kompletten Daten geschreddert.
Aber was ist eigentlich, wenn das Board einen defekt hat, oder die CPU? Können da auch solche schleichenden Fehler einen Totalausfall verursachen?
Das ist eine Diskussion in der Art, Leute lasst euch nicht impfen, das kann Nebenwirkungem haben
und es sind schon Leute daran gestorben. Dass eventuell viel mehr Personen durch die Impfung keinen Schaden hatten wird übersehen.
Man muss einfach akzeptieren, dass es Probleme gibt die auch bei ZFS zu korrupten Dateien führen können. Daher braucht man auch bei ZFS ein Backup weil Hardwareprobleme, egal ob RAM, CPU, PSU, Blitzschlag oder wasauchimmer alles schrotten können. ECC RAM verringert das Problem lediglich. Im Profibereich ist es eh selbstverständlich.
Fehler auf 1-20 TB Storage die ZFS bei (Home)-Servern dank Prüfsummen reparieren kann (z.B. durch Silent Errors, Kabel, PSU, Controller oder Backplanes) sind nunmal sehr sehr viel wahrscheinlicher als ein Ram-Kipper bei 4-32 GB RAM wenn man eine in der Größenordnung ähnliche Eintrittswahrscheinlichkeit annimmt.
Diese globale Warnung (kein ZFS ohne ECC) wäre nur dann sinnvoll, wenn unentdeckte RAM Fehler 1000x wahrscheinlicher wären als Fehler auf den Platten. Wenn dem aber so wäre, dann müssten in den Foren Tausende über verlorene Daten jammern denn nicht nur ich habe zu Hause ein ZFS (Backup)System ohne ECC.
Siehe auch meinen Kommentar in
http://www.hardwareluxx.de/community/f101/debian-nas-im-eigenbau-1050756.html#post22961198
Zuletzt bearbeitet:
oc_parts
Enthusiast
- Mitglied seit
- 26.03.2006
- Beiträge
- 2.741
Autoexpand ist on. Aber es ist immernoch bei der gleichen Größe.
Menu System hab ich gar nicht. Ich habe Napp it auf Ubuntu Server installiert.
hmm, habe es unter Linux noch nicht probiert.
ZoL sollte da aber wie Illumos/Solaris arbeiten.
Unter Linux laufen unter napp-it momentan nur die grundlegenden ZFS Sachen -
System-Einstellungen erst wenn ich mal Zeit dazu finde.
Als Alternative bleiben:
- Putty
- cmd Eingabe
- ein privates Menü
Nach dem ich mir den Thread den zos oben aufgeführt hat (und die darin verlinkten Threads) auch noch durchgelesen habe, stellt sich mir immer noch die Frage, ob nur der fehlende ECC RAM so einen schleichenden Tod des Pools bei ZFS herbeiführen kann?
Was ist denn, wenn das Maionboard eine Macke hat? Oder die CPU selbst was falsch berechnet?
Ich hatte vor Jahren mal so ein Fall, PC lief (mit Windows) ganz "normal", nur passierten ständig seltsame Dinge, immer mal wieder nicht gedrückte Zeichen im Dokument, falsche Berechnungen in Excel, etc. - aber kein Absturtz des Systems! Ich zweifelte schon an mir
Nach tagelangen Tests und Einzelaustausch ALLER Komponenten zeigte sich dann, das tatsächlich die CPU selbst einen "Schuss" hatte.
Was ist denn, wenn das Maionboard eine Macke hat? Oder die CPU selbst was falsch berechnet?
Ich hatte vor Jahren mal so ein Fall, PC lief (mit Windows) ganz "normal", nur passierten ständig seltsame Dinge, immer mal wieder nicht gedrückte Zeichen im Dokument, falsche Berechnungen in Excel, etc. - aber kein Absturtz des Systems! Ich zweifelte schon an mir
Nach tagelangen Tests und Einzelaustausch ALLER Komponenten zeigte sich dann, das tatsächlich die CPU selbst einen "Schuss" hatte.Das ist mir schon klar das es keinen 100% Schutz gibt, darum geht es mir auch nicht. Ich finde nur Fehler schlimm, die schleichend sind, die man erst bemerkt wenn es dann zu spät ist und man sich bis dahin in Sicherheit wiegt. Wenn das Netzteil ausfällt, machts *bumms* und die Kiste ist aus, das Dateisystem sollte durch ZFS aber noch in Ordnung sein. Wie gesagt, ich wollt nur wissen ob andere Komponenten oder Umstände auch solche Dinge verursachen können.
ludwinator
Enthusiast
- Mitglied seit
- 28.12.2006
- Beiträge
- 527
... und genau diese "schleichenden Fehler" kann ZFS verhindern, im Gegensatz zu fast allen anderen Filesystemen.
ZFS korrigiert keine Fehler, die keine sind und meldet sogar, in welcher Datei das Problem aufgetreten ist.
Verzicht auf ECC provoziert bei ZFS nicht mehr und auch nicht weniger Probleme als anderswo auch. Ich halte die ganze Diskussion sowieso für überflüssig und bin schon lange der Meinung, das ECC zum Standard in jedem Rechner gehören sollte. Kommt mir vor wie früher, als die Fließkommaeinheiten noch extra Prozessoren waren. Spricht heute kein Mensch mehr drüber, das hat man einfach drin. So sollte es bei ECC auch sein.
cu
ZFS korrigiert keine Fehler, die keine sind und meldet sogar, in welcher Datei das Problem aufgetreten ist.
Verzicht auf ECC provoziert bei ZFS nicht mehr und auch nicht weniger Probleme als anderswo auch. Ich halte die ganze Diskussion sowieso für überflüssig und bin schon lange der Meinung, das ECC zum Standard in jedem Rechner gehören sollte. Kommt mir vor wie früher, als die Fließkommaeinheiten noch extra Prozessoren waren. Spricht heute kein Mensch mehr drüber, das hat man einfach drin. So sollte es bei ECC auch sein.
cu
Zuletzt bearbeitet:
Das ist ja schön und gut, aber nicht jeder Rechner schluckt ECC-RAM. Beispiel: Ich habe hier noch einen Mac Mini 2012 stehen und laut Apples Spec's funzt ECC hier nicht, Zitat:
Hintergrund ist der, dass ich hier eine SSD (256GB), eine HDD (1TB) und 16GB RAM (non-ECC) drin habe und die 1TB HDD noch ganz frei ist (also kein Fusion-Drive). Ich habe zunächst überlegt mal OpenZFS on OSX zu probieren. Deshalb ist diese Diskussion für mich durchaus interessant.
da kann ich nur zustimmen und darum werde ich das bei mir jetzt auch ändern. Dazu bräuchte ich bzgl. Hardware aber Eure Hilfe, hier mal meine bisherige Konfig:
Intel DQ67SW
i5-2500T
16 GB RAM (ohne ECC)
Das System ist ein AIO, realisiert mit Proxmox und Nas4Free. Dazu hab ich einen einfachen PCIe-SATA-Controller im System, an der eine kleine SSD für Proxmox hängt. Den onBoard SATA-Controller mit seinen vier internen Ports hab ich an Nas4Free durchgereicht, an welchen zwei Mirror-Pools hängen (2x 250 GB SSD's für VM's, 2x 3TB HD's für den Rest). N4F gibt den Datastore der SSD's per NFS zurück an Proxmox für weitere VM's. Das ganze lief jetzt 3 Jahre stabil durch, hoffe ich zumindest (in Bezug auf ECC....), aufgefallen ist mir aber bisher nix.
Da weder mein bisheriges Board noch die CPU ECC unterstützen, bräuchte ich also beides neu, plus ECC RAM natürlich. Von der Leistung her hat mir das bis jetzt eigentlich gereicht, muss also was die CPU an geht nicht das Top-aktuellste sein, mir gings damals (und heute) mehr um Preis/Leistung/Energieverbrauch, da 24h Betrieb. Das Board sollte aber bzgl. AIO auf alle Fälle wieder VT-D unterstützen (die CPU natürlich auch). OnBoard sollte USB-3, ein oder zwei vernünftige Gigabit-Lan-Port(s) und mindestens 4 SATA-Ports zum durchreichen vorhanden sein.
Wäre nett, wenn Ihr mir hierzu ein paar Empfehlungen geben könntet.
ludwinator
Enthusiast
- Mitglied seit
- 28.12.2006
- Beiträge
- 527
Mein Favorit:
Supermicro X10SLM-F
Xeon E3-12xx V3
2*8GB DDR3 Ram ECC
Supermicro X10SLM-F
Xeon E3-12xx V3
2*8GB DDR3 Ram ECC
Das Board ist top für jeden ESXi und NAS/SAN Server
Eine andere Optione ist das X10SL7-F
Supermicro | Products | Motherboards | Xeon® Boards | X10SL7-F
Das enthält prakisch einen LSI 9207 - einen der besten HBA SAS Controller.
Der kostet separat soviel wie das SM Board mit dem Controller - ideal für AIO
Zuletzt bearbeitet:
ZFS- Fragen
Hallo,
ich hoffe hier mit meinen Fragen richtig zu sein. Denn die Forums-Suchfunktion hat mir keine Treffen ausgeworfen.
Ist es möglich, im laufendem Betrieb eine ZFS-HDD extern (per E-S-ATA) am Server zu mounten? Oder muß der Server neu starten um die externe Platte zu erkennen?
Habe ich es richtig verstanden, das "scrub" nur eine Überprüfung der Datenintegrität ist?
WAs hat es mit dem "Snapshot" auf sich?
Warum "verbrät" FreeNAS 9.2.x auf einer 4 TB-HDD ein halbes TB für sich allein?
Ist "Replizierungsaufgabe" mehr als nur ein Backup?
Soviel für heute...
Thomas
Hallo,
ich hoffe hier mit meinen Fragen richtig zu sein. Denn die Forums-Suchfunktion hat mir keine Treffen ausgeworfen.
Ist es möglich, im laufendem Betrieb eine ZFS-HDD extern (per E-S-ATA) am Server zu mounten? Oder muß der Server neu starten um die externe Platte zu erkennen?
Habe ich es richtig verstanden, das "scrub" nur eine Überprüfung der Datenintegrität ist?
WAs hat es mit dem "Snapshot" auf sich?
Warum "verbrät" FreeNAS 9.2.x auf einer 4 TB-HDD ein halbes TB für sich allein?
Ist "Replizierungsaufgabe" mehr als nur ein Backup?
Soviel für heute...
Thomas
Könnt Ihr mir zuällig sagen, wie die genannten SM-Boards im Stromverbrauch liegen? Vielleicht einfach mit Euren Konfigurationen.
Das "X10SL7-F" hat schon was, da wär ich, für meine Verhältnisse zumindest, für die Zukunft gerüstet
gea: das heisst ich könnte am "kleinen" OnBoard-Controller das Betriebssystem laufen lassen, und den LSI an die VM durchreichen?
Das "X10SL7-F" hat schon was, da wär ich, für meine Verhältnisse zumindest, für die Zukunft gerüstet
gea: das heisst ich könnte am "kleinen" OnBoard-Controller das Betriebssystem laufen lassen, und den LSI an die VM durchreichen?
Zuletzt bearbeitet:
Könnt Ihr mir zuällig sagen, wie die genannten SM-Boards im Stromverbrauch liegen? Vielleicht einfach mit Euren Konfigurationen.
Das "X10SL7-F" hat schon was, da wär ich, für meine Verhältnisse zumindest, für die Zukunft gerüstet
gea: das heisst ich könnte am "kleinen" OnBoard-Controller das Betriebssystem laufen lassen, und den LSI an die VM durchreichen?
Die SM Boards brauchen minimal mehr Strom als Desktop Boards, vor allem wegen den 3 Nics (2 x Intel + IPMI)
und der IPMI Management Option. Das ist es aber wert.
Der LSI Controller braucht nochmal ca 5-10W
Zm LSI HBA:
Ja, so mache ich das bei meinem napp-in one Konzept unter ESXi
Auf einer Sata Platte (ab 30GB) liegt ESXi und auf dem lokalen datastore dann OmniOS als Storage VM.
Den LSI Controller reiche ich dann per vt-d an OmniOS durch damit ZFS direkten Zugriff auf die Storage Hardware hat.
Der wird dann von OmniOS per SMB/NFS/iSCSI wasauchimmer bereitgestellt - auch als shared NFS Storage für weitere VMs.
Morpheus2200
Semiprofi
- Mitglied seit
- 04.08.2001
- Beiträge
- 30.945
Nochmal zur ECC Diskussion hier.
Nicht unterschätzen sollte man auch, dass erst über ECC eine hardwareseitige Erkennung der korrigierbaren Speicherfehler möglich wird.
Ich denke das sich ECC im Endkundenbereich nicht durchgesetzt hat/nicht bald durchsetzen wird weil man die Fehler findet und zählen kann. Ich glaube ein nicht gerade kleiner Teil des Arbeitsspeichers der heute ohne ECC verkauft wird würde zurück an den Hersteller gehen.
Nicht unterschätzen sollte man auch, dass erst über ECC eine hardwareseitige Erkennung der korrigierbaren Speicherfehler möglich wird.
Ich denke das sich ECC im Endkundenbereich nicht durchgesetzt hat/nicht bald durchsetzen wird weil man die Fehler findet und zählen kann. Ich glaube ein nicht gerade kleiner Teil des Arbeitsspeichers der heute ohne ECC verkauft wird würde zurück an den Hersteller gehen.
OmniOS root pool wird nicht funktionieren,
ein Datenpool sollte mit den entsprechenden Einstellungen in der power.conf schlafen gehen sofern nichts darauf zugreift.
Eventuell muss man den fmd service stoppen (Fehlerprüfung).
Ich mach das aber nie, da es eine Minute und mehr dauern kannm, bis ein schlafender Pool wieder reagiert.
Dann doch lieber ausschalten (z.B. per shutdown job am Abend) und einschalten wenn man ihn wieder braucht
(manuell oder remote per IPMI)
Daneben gibt es SCSI Tools wie sdparm mit denen man Platten "auf Befehl" schlafen lassen kann.
Linux sdparm utility
oc_parts
Enthusiast
- Mitglied seit
- 26.03.2006
- Beiträge
- 2.741
Ich nutze zol auf nem ubuntu server. Und es gibt keinen root pool.
Manuel starten wäre unbequem. Denn der fileserver sollte automatisch erwachen wenn ein client auf ein share zugreift. 1m wäre noch ok.
Wol wäre evtl noch eine option wenn ich das in meine hausautomation einbinden kann. Aber die 1. Option wäre standby.
Gesendet von meinem SM-N9005 mit der Hardwareluxx App
Manuel starten wäre unbequem. Denn der fileserver sollte automatisch erwachen wenn ein client auf ein share zugreift. 1m wäre noch ok.
Wol wäre evtl noch eine option wenn ich das in meine hausautomation einbinden kann. Aber die 1. Option wäre standby.
Gesendet von meinem SM-N9005 mit der Hardwareluxx App
Noch mal bzgl. Board: Gibt es das auch mit 3 PCIe Steckplätzen? Zwei brauche ich nämlich schon mal, einer auf Ersatz wäre ganz gut gewesen.
Gäbe es denn auch noch Alternativen zu den SuperMicro Borads? Oder stellen die schon das beste Preis/Leistungsverhältnis?
