[Sammelthread] ZFS Stammtisch

Die Meßgrößen sind oft nicht vergleichbar, mal wird Steady State worstcase angegeben, mal Maximum, mal irgendwelche "typischen Szenarien". Es kommt immer drauf an, wie lange wieviel mit welchen Zugriffsmustern man draufschreibt. In den Preisvergleichsportalen und auch bei den Händlern siehst Du das nicht. Es ist halt was anderes, ob man daheim relativ zaghaft schreibt oder im Rechenzentrum Oracle-Server beständig ihre TB's an Tablespaces, Tempdaten und Redo-Logs für Datawarehouse-Anwendungen draufdonnern.
Da muss man bei den jeweiligen Herstellern und Modellen ganz genau in den Datasheets und Handbüchern lesen.

Meine SM863 960GB sind z.B. ja auch auf knapp unter 30k IOPS write 4k angegeben; hier sind es worst case IOPS. Unter Idealbedingungen erreichen die durchaus auch 90-95% der 850pro (=vergleichbare Consumer-Baureihe der gleichen Generation). D.h. hier regelt z.B. keine Firmware die SM863 ab (gibts das bei DC-SSD?), sondern ich bekomme was Controller+Flash "hergeben".
Zum Vergleich: die 850pro ist ja durchaus eine sehr ordentliche SSD und war lange Zeit führend im Sata-Bereich für Consumer. Die kann Dir durchaus auf 5-6 MB/s bei Sync-Writes einbrechen; haben User hier schon berichtet.

Btw, bei Storagereview.com und Anandtech schau ich da diesbzgl. recht gerne rein.
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Frage: Welche Höchstgeschwindigkeit erreicht ein VW Käfer?
Zwischenfrage: Bergauf oder im freien Fall?

So muss man auch Testergebnisse interpretieren. Wenn Intel bei einer Datacenter DC3700-100 (https://ark.intel.com/content/www/d...0-series-100gb-2-5in-sata-6gb-s-25nm-mlc.html) 19000 write iops angibt, so glaube ich das und die kann das auch unter Dauerlast. (DIe DC 3700 war lange ziemlich die beste SSD überhaubt wenn es um Schreiben ging).

Wenn auf einer billigen Desktop SSD was von 100000 write iops bei 4k steht so erinnert das an Peterchens Mondfahrt. Kann die allenfalls in einem definierten Testumfeld im leeren/Neuzustand für kurze Zeit, nicht im Realbetrieb.
 
T-51b schrieb:
Ich habe schon soo viel gutes über FreeNAS gehört, daher wollte ich es einfach mal ausprobieren.
Und auch genau von dieser Konstellation aus Hypervisor + FreeNAS VM + HBA Passtrough habe ich schon unzählige male gelesen.
Zum Vergrößern anklicken....

Ich bin vor einiger Zeit im Rahmen eines Hardware-Refreshs von der hier üblichen all-in-one Lösung (ESXi + HBA an Solaris VM durchreichen) auf Proxmox umgeschwenkt. Da ich mit der native ZFS-Lösung bei Proxmox nach einiger Zeit nicht zufrieden war, war auch mein erster Ansatz, Solaris in eine VM unter Proxmox zu sperren und darüber die NAS-Funktionalität bereitzustellen. Ich habe das nicht mit aller Konsquenz zuende getrieben, aber Solaris in einer VM unter Proxmox lief nicht wirklich rund. Wie das konkret bei FreeNAS aussieht kann ich nicht sagen, aber ich für meinen Teil bin nach dem "Versuch" wieder zurückgekehrt zur ESXi-Lösung...
 
Als ich vor ca 10 Jahren erstmals das Konzept einer virtualisierten Storage Appliance (ESXi+Solaris/OI/OmniOS mit napp-it) vorstellte wurde ich dafür im FreeNas Forum förmlich verrissen (langsam, nicht zuverlässig, geht gar nicht, Schnapsidee). Erst seit diesem Artikel in 2015 fand die Idee auch unter FreeNAS Anhänger und wird neuerdings auch da offiziell als Option angesehen.

b3n.org

FreeNAS 9.10 on VMware ESXi 6.0 Guide

This is a guide which will install FreeNAS 9.10 under VMware ESXi and then using ZFS share the storage back to VMware. This is roughly based on Napp-It’s All-In-One design, except that it uses FreeNAS instead of OminOS. This post has had over 160,000 visitors, thousands of people have used this...
b3n.org b3n.org
 
Zuletzt bearbeitet:
negotiator schrieb:
Wie das konkret bei FreeNAS aussieht kann ich nicht sagen, aber ich für meinen Teil bin nach dem "Versuch" wieder zurückgekehrt zur ESXi-Lösung...
Zum Vergrößern anklicken....

Läuft mit Freenas super ( also Freenas auf PVE), mitlerweile bin ich aber von VM aufs Bleich gewechselt. Liegt aber eher am RAM und am Gehäuse :-) und nicht an der Performance.

Mit ESXi wurde ich irgendwie nie so recht warm. Das einzige was mich am PVE nervt ist das ZFS over iSCSI nur mit VM's läuft und nicht mit CT; ist aber wohl was in der mache.
 
www.computerbase.de

PCI-Express-Adapter: Einbaurahmen für 2,5-Zoll-Laufwerke kann Hot Swap

Eine ausgefallene PCIe-Adapterkarte für 2,5-Zoll-Laufwerke hat Icy Dock mit der ToughArmor MB839SP-B vorgestellt. Sie unterstützt Hot Swap.
www.computerbase.de www.computerbase.de

Kann man sowas problemlos mit OmniOS benutzen oder kann es da Probleme geben wegen Treiber und so?

gea schrieb:
Den Wert von etwas erkannt man dann meist erst wenn es weg ist....
Ich würde daher zwei Pools, einen aus SSD (Mirror) für VMs und einen aus Plattem (Z1 oderZ2) für Daten und Backup der VMs machen. Ein externes Backup (z.B. USB Disk) der wichtigsten Daten sollte man zusätzlich zu Raid und Snap Versionierung als Disasterbackup mit planen.

Wenn einem die Betriebssicherheit der VMs etwas bedeutet, dann brauchts sync write + powerloss protection (sonst kann man auch auf sync Absicherung der Schreibvorgänge pfeiffen). Bei einem SSD Pool braucht man ein Slog meist nicht, da der Pool schnell genug ist, vgl Punkt 8. in https://napp-it.org/manuals/index.html

Da sieht man auch dass ein Plattenpool mit 500 MB/s Schreibperformance mit aktiviertem sync gerne mal auf 40MB/s einbricht.
Zum Vergrößern anklicken....

Würde das nicht auch heißen Daten und Backup auf einem SSD Pool dass dort Powerloss Protection verzichtbar ist? Oder mit anderen Worten ist ein Pool aus HDD "unsicherer" was Stromausfall angeht als ein Pool aus SSDs?
 
Zuletzt bearbeitet:
1. Bei dem Adapter handelt es sich um einen Sata Controller mit Wechselrahmen. Hotplug ist da kein Problem. Ob der Sata Chip was taugt kann ich niocht sagen.

Anders sieht es mit U.2 (NVMe) Hotplug aus. Das ist etwas komplizierter im Handling, sollte aber auch funktionieren.

2. Powerloss Protection.
Wenn eine Platte einen Schreibvorgang bestätigt und dann der Rechner crasht, dann kommt es darauf an. Bei einer mechanischen Platte kann das OS den writeback cache deaktivieren und die Daten sind sicher auf der Platte. Bei einer SSD ohne plp kann es sein, dass die Daten verloren sind.

Bei einer mechanischen Platte braucht man daher kein Feature "Powerloss Protection". Jede Platte kann das. Bei einer SSD sieht das anders aus. Da ist nur bei besseren SSD mit plp garantiert dass Daten tatsächlich gespeichert sind. Das mag bei einem Desktop Rechner ok sein, bei einem Storageserver möchte man das eher nicht haben. Eine nicht sicher gespeicherte Protokollierung der letzten bestätigten Schreibvorgänge im Ramcache, egal onpool (ZIL) oder als Slog SSD macht überhaupt keinen Sinn wenn man gerade damit einen Datenverlust im Crashfall verhindern will.
 
gea schrieb:
Ein großer Schreibpuffer ist schneller und die Absicherung wird aufwändiger. Aber auch wenn der nur ein paar Hundert MB groß ist wie bei den meisten Hardwareraids oder Platten bleibt das Problem das gleiche. Sobald man mit virtuellen Platten und darauf enthaltenen Dateisystemen arbeitet MUSS ein Commit mit dem einer VM ein Schreibvorgang bestätigt wird bedeuten, dass die Daten auf Platte sind - andernfalls kann das Dateisystem korrupt sein.

Wenn man das Problem nicht ignorieren mochte oder kann, dann bedeutet das normale Platten mit writeback cache deaktiviert oder SSD/NVMe und Powerloss Protection. Bei Hardwareraid ist dazu Cache+BBU Pflicht, bei ZFS das Aktivieren von sync das gleiches leistet wie Cache+BBU bei Hardwarraid (Absicherung des Schreibcaches).

Ohne ZFS und mit anderen Softwareraids kann man das Problem nur ignorieren und hoffen dass alles gutgeht. Ein Absicherung der diversen Schreibcaches ist da nicht möglich.
Zum Vergrößern anklicken....

Sorry dass ich den doch schon etwas älteren Beitrag nochmal hoch hole, aber ich will mich vergewissern, dass ich es auch tatsächlich richtig verstanden habe:

- Wenn ich ein OS wie z.B. Debian direkt auf der SSD installiere, dann ist KEINE PowerLoss Protection notwendig wegen CopyOnWrite von ZFS? Außerdem muss Sync nicht explizit aktiviert sein? Das gleiche gilt wenn ich die SSD nur als Speicher für Dateien verwende?

- Nur wenn auf der SSD VMs liegen, dann ist eine PowerLoss Protection notwendig, da ZFS die Konsistenz nicht sicherstellen kann, weil es nicht "in die VM rein gucken" kann? Außerdem muss hier Sync in ZFS aktiviert sein?

- Oder man nimmt normale Festplatten, da die von dem Problem nicht betroffen sind. Allerdings muss man dann den Cache der Platte deaktivieren. (Was vermutlich auch zu Performanceverlust führt?)

- Das alles ist aber nur relevant im Fall eines Server-Absturzes, Stromausfall o.Ä. Im Normalbetrieb ist PLP & Sync quasi "nutzlos"?

Das ganze Thema verwirrt mich mehr als dass ich einen Nutzen daraus ziehen könnte. :d
 
gea schrieb:
2. Powerloss Protection.
Wenn eine Platte einen Schreibvorgang bestätigt und dann der Rechner crasht, dann kommt es darauf an. Bei einer mechanischen Platte kann das OS den writeback cache deaktivieren und die Daten sind sicher auf der Platte. Bei einer SSD ohne plp kann es sein, dass die Daten verloren sind.
Zum Vergrößern anklicken....
Aber unsicherer als bei einem Desktop PC bin ich dann doch auch nicht. Ich möchte einen SSD Mirror als "Datengrab" verwenden für Fotos, Musik etc. Ergo einmal schreiben, und dann meist nur noch lesen. Ich sehe jetzt immer noch nicht inwiefern PLP bei einem derartigen Szenario so wichtig sein sollte, vorallem wenn man selten schreibt.
Der Stand bis zum letzten Snapshot sollte doch perse immer auf den SSDs selbst sein.
Bei VMs kann ich es ja noch nachvollziehen, aber wenn wir darüber reden dass ich Filme,Bilder, Musik auf einem SSD Pool habe ist das für mich weniger nachzuvollziehen inwiefern hier PLP wichtig sein sollte.

Meine Idee wäre jetzt 2 Pools zu machen, einmal einen mit SSDs mit PLP für VMs und Dokumente. Und einen weiteren für Bilder,Musik,Videos ohne PLP der den HDD Mirror ablöst.
 
@CommanderBond
Sollte einem die Performance nicht so wichtig sein und man mit max. 1 TB pro SSD leben könnte, dürfte diese wohl auch "reichen".

Wo kein Dram Cache vorhanden ist dürfte es auch keine Propleme geben die es ggf mit Cache und ohne PLP gibt.


Wobei ich mich Frage ob man dass ohne VMs mit hoher Schreib/Leseleistung überhaupt spüren würde.So könnte man das ja ggf abstufen je nach Pool - da spart man ja ggf doch etwas an Geld. Obs das auf Zeit dann bringt ist dann was anderes.

Sollte man Pcie SSds nutzen wollen/können.
 
CommanderBond schrieb:
Bei VMs kann ich es ja noch nachvollziehen, aber wenn wir darüber reden dass ich Filme,Bilder, Musik auf einem SSD Pool habe ist das für mich weniger nachzuvollziehen inwiefern hier PLP wichtig sein sollte.
Zum Vergrößern anklicken....
So wie ich es verstanden habe ich es in dem Szenario auch vollkommen irrelevant.
Sollte so eine großte Datei wie ein Video/Film geschrieben werden, während der Strom ausfällt, dann ist diese Datei sowieso kaputt. Egal ob mit oder ohne PLP.

Bei einer VM wäre aber nicht nur eine Datei kaputt, sondern das ganze Dateisystem - deshalb ist es dort wichtig.

Aber mal ne andere Frage: Warum genau einen SSD Mirror für solch einen Zweck? HDDs lasten Gbit Netzwerk doch schon aus. Das reicht doch. :)
 
T-51b schrieb:
Das ganze Thema verwirrt mich mehr als dass ich einen Nutzen daraus ziehen könnte. :d
Zum Vergrößern anklicken....

Sun hat ZFS ca 2005 mit dem Ziel vorgestellt, alle wesentlichen Ursachen eines Datenverlusts zu bekämpfen. Dazu zählen Raid ohne write hole Problem, Crashsicherheit durch Copy on Write mit Snaps/ Versionierung und Prüfsummen auf Daten und Metadaten.

Es gibt nur wenig, was die Sicherheit von ZFS aushebeln kann. Dazu zählen Ram-Fehler (vermeidbar mit ECC RAM) und Caches beim Schreiben (RAM oder Festplattencache). Den RAMcache kann ZFS mit sync write selber absichern. Einen platteninternen Cache kann ZFS nicht sichern. Das muss die Platte (hier SSD oder NVMe) selber leisten. Billige Desktop SSD können das nicht, Enterprise SSD/NVMe immer.

Die Frage die sich hier stellt sehe ich wie beim Autofahren. Fahre ich einen Oldie ist Personenschutz bis auf Sicherheitsgurt und Nackenstütze irrelevant. Man kann aber auch der Ansicht sein, dass aktuelle Features wie verbesserte passive Sicherheit, ABS und ESP notwendig sind. Genauso verhält es sich mit ZFS das eben Sicherheitsmerkmale nach Stand der Technik bietet die ältere Systeme wie ext4 oder ntfs nicht bieten. RAM ohne ECC oder Platten ohne Powerloss Protection ist dann wie ein Auto mit ESP bei dem man ESP ausschaltet.

Privat hatte ich erst einen schweren Unfall als mir jemand stehend mit 50kmh hinten auffuhr. Ohne Nackenstütze wäre ich nicht mehr. Dennoch würde ich kein Auto ohne aktuelle Sicherheitsfeatures wie ABS oder ESP fahren wollen. Man hat da immer eine Wahl. Wie immer hat eine Wahl aber auch Konsequenzen.
 
Zuletzt bearbeitet:
Hätte auch mal wieder zwei Fragen zu napp-it AiO.

Und zwar sichere ich meine SSD mit den VMs auf zwei Platten per MC. Für die Sicherungen habe ich jetzt im napp-it je ein ZFS Dateisystem angelegt. Aber prinzipiell geht das ja auch ohne. Ist denn das schon ZFS ohne angelegtes Dateisystem? Die Festplatten wurden ja nicht formatiert, oder so. Wie muss ich mir das vorstellen? Ist MC überhaupt das Mittel der Wahl, die vSphere Maschinen im ausgeschaltetem Zustand zu sichern?

Dann zu den Snapshots: kann man die auf der Platte irgendwo sehen? Also im Dateisystem... Ich habe jetzt bei den zwei Backup- und der Datenplatte je ein Snapshot angelegt, das reicht mir eigentlich. Aber angenommen ich möchte da eine VM von vor dem Snapshot mit der aktuellen Version ersetzen, wie gehe ich da vor? Snapshot löschen, gesicherte VM löschen, die aktuelle Version sichern und dann wieder einen Snap anlegen wär jetzt das einzige, was mir dazu in den Sinn kommt. Und wie kann ich ohne zurückspringen auf einen alten Stand da jetzt eine VM bzw. Datei aus dem "Urzustand" wieder raus fischen, ohne die Snaps zu verlieren?

Gruss und danke
 
Ein ZFS Pool selber ist auch ein ZFS Dateisystem. Für selber angelegte Dateisysteme ist das quasi das Parent Dateisystem wo man Defaults festlegen kann.

Die ideal Sicherungsoption wäre ZFS Replikation. Ist viel schneller als ein Copy mit midnight commander und erhält Dateisystem Attribute. Man kann damit auf einen anderen Pool oder Dateisystem lokal oder im Netz sichern. Lokal wäre eine USB Platte mit einem ZFS Pool ideal. Siehe Menü Jobs > Replikation. Ein Replikations Job kümmert sich automatisch um die Snaps. Man könnte damit (per ESXi hot snap) auch laufende VMs sichern.

Snaps sind im Dateisystem erreichbar unter dateisystem/.zfs/snapshot (mc) oder per SMB unter share\.zfs\snapshot. Per SMB ist der einfachste Zugriff über einen Maus-Rechtsklick auf einen beliebigen Ordner und dann mit Eigenschaft > vorherige Version.
 
T-51b schrieb:
Aber mal ne andere Frage: Warum genau einen SSD Mirror für solch einen Zweck? HDDs lasten Gbit Netzwerk doch schon aus. Das reicht doch. :)
Zum Vergrößern anklicken....

Eine Festplatte liefert sequentiell (Video auf eine leere Platte schreiben) ca 150 MB/s. Eine VM oder gar parallell mehrere VMs arbeiten aber nicht sequentiell sondern erzeugen wahlfreie Zugriffe. Eine mechanische Festplatte kann dann ca 100 iops und noch 50 MB/s, mit aktiviertem sync vielleicht nur 5-10 MB/s.

Eine gute SSD hat nicht nur sequentiell bis zu 500 MB/s sondern vielleicht 30000 iops und erreicht selbst mit sync > 50 MB/s. Eine Top NVMe wie eine Intel Optane 48x/900 sogar mit sync 800 MB/s bei 500000 iops. Damit kann man sogar 10G mit aktiviertem sync auslasten. (Ultrasicherer SMB Filer)
 
Zuletzt bearbeitet:
Also die grundsätzlichen Vorteile einer SSD sind mir durchaus bewusst. :d
Und für VMs sehe ich durchaus den Vorteil.
Mir war nur nicht ganz klar, warum man SSDs für den simplen Anwendungsfall "Speichern von Video/Musik/Fotos" verwenden sollte.

Aber ja, Stromverbrauch, Lautstärke und Platz sind natürlich ein guter Grund, solange man nicht zu viel Speicher benötigt. Sonst wirds teuer. :d
 
T-51b schrieb:
Also die grundsätzlichen Vorteile einer SSD sind mir durchaus bewusst. :d
Und für VMs sehe ich durchaus den Vorteil.
Mir war nur nicht ganz klar, warum man SSDs für den simplen Anwendungsfall "Speichern von Video/Musik/Fotos" verwenden sollte.

Aber ja, Stromverbrauch, Lautstärke und Platz sind natürlich ein guter Grund, solange man nicht zu viel Speicher benötigt. Sonst wirds teuer. :d
Zum Vergrößern anklicken....
Für solche Daten lohnen sich dann HDDs, aber VMs würde ich nur auf SSD Pools laufen lassen, oder ein HDD Pool mit massig RAM + Optane SLOG. Hab ich momentan bei mit noch bis mein NVMe Pool fertig ist.
 
Zuletzt bearbeitet:
T-51b schrieb:
Aber ja, Stromverbrauch, Lautstärke und Platz sind natürlich ein guter Grund, solange man nicht zu viel Speicher benötigt. Sonst wirds teuer.
Zum Vergrößern anklicken....
Das war ja der Grund, ich brauche nur ein paar TB Platz. Problem an der Sache ist aber mit PLP zahlt man gut das doppelte oder andersherum ich bekomme in etwa doppelt soviel Platz wenn ich auf PLP verzichte.
Gründe sind Stromverbrauch und auch dass 2,5er HDD auch nochmal ne Ecke langsammer sind als 3,5er HDD, Sprich ich benötige 3,5er Schächte für HDDs, bei SSDs kann ich auf 2,5" gehen.
Festplatten in den Standby schicken ist auch nicht möglich wenn man regelmäßig Snapshots macht und sie dann nur dafür jedesmal aufwachen oder die Erstellung der Snapshots selbst die HDDs am Standby/Spindown hindern.
So wirklich klar ist mir also auch weiterhin nicht wo der Vorteil von PLP liegt bei dem Anwendungsfall dass ich einfach nur stumpf Videos und Fotos speichern will.

Wäre es vielleicht möglich nur dann einen Snapshot zu erstellen wenn die Platte auch läuft und diese nicht extra nur für die Erstellung des Snapshots hochzufahren, da dieser in dem Fall dann doch sowieso die Größe 0 hätte.
Oder anders ausgedrückt dass ein Snapshot erstellt wird kurz bevor das OS die Platte schlafen legt?
Auf mein NAS schreibe ich manchmal nur 1mal die Woche Daten oder noch seltener, Snapshots im 15minuten Takt will ich aber dennoch haben wenn ich grad arbeite, das war auch der Grund auf SSDs statt HDDs zu setzen weil mir das durchlaufen lassen nur damit lauter Snapshots der Größe 0Byte erstellt werden sehr sinnlos erscheint. Und die Platten ständig spinup spindown machen zu lassen ist genauso dumm.

Soll heißen mit HDDs habe ich dann nur die Wahl zwischen hohem Stromverbrauch und sie laufen 99,99% der Zeit umsonst, oder ich verschleiße die Teile nur um Snapshots zu erstellen durch hochfahren nur der Erstellung des Snapshots wegen. Alternative 2,5er HDD, die haben geringeren Stromverbrauch, sind aber echt Übel bei der Leistung.

Wenn die automatische Erstellung von "Snaps" irgendwie smarter werden würde, fände ich das sehr zu begrüßen.
 
CommanderBond schrieb:
Das war ja der Grund, ich brauche nur ein paar TB Platz. Problem an der Sache ist aber mit PLP zahlt man gut das doppelte oder andersherum ich bekomme in etwa doppelt soviel Platz wenn ich auf PLP verzichte.
..

Wenn die automatische Erstellung von "Snaps" irgendwie smarter werden würde, fände ich das sehr zu begrüßen.
Zum Vergrößern anklicken....

Man hat ja die Wahl. Für einen Heim-Mediaserver gelten sicher andere Ansprüche als z.B. für einen Firmen oder Hochschul VM, Mail- oder Multiuser Filer. Meiner ersten VM Filer mit SSDs hatten auch noch kein PLP. Das gab es bei den ersten SSDs noch nicht. Die liefen jahrelang auch ohne Probleme. So häufig sind Abstürze bei uns ja nicht. Ausserdem haben die eine UPS. Meine altuellem Systeme haben aber durch die Bank PLP, Für professional use ist der Aufpreis für PLP nicht zuletzt bei den neueren Intel SSD einfach zu gering um da ein vermeidbares Risiko einzugehen.

SSDs organisieren zudem im Hintergrund automatisch Daten neu (Garbage Collection) oder werden durch trim optimiert. Diese Prozesse laufen dauerhaft oder lange. Auch da bringt plp einen Sicherheitsvorteil, nicht nur für sync oder atomare Schreibvorgänge bei denen ZFS davon ausgeht dass ein Commit deutet dass die Daten auf Platte sind. Aber klar, wir reden hier von Sicherheitsanforderungen über die man sich bei älteren Dateisystemen mangels Lösungsmöglichkeiten gar keine Gedanken gemacht hätte.

Autosnap nur wenn Plattenaktivität. Das ist sicher keine typische Anforderung und schon gar nicht bei professioneller Nutzung. Bei napp-it ließe sich das selber durch ein eigenes kleines Script als "other job" erledigen. So ein Script müsste iostat aufrufen z.B. "iostat -xtcn 50 3". In Perl ist das ein Script wie
Code: 
$r=`iostat -xtcn 50 3 | grep poolname`;
@t=split(/\n/,$r);
if ($t[1] eq $t[2]) {   # keine Aktivität
   # setze job auf manuell..
} else {
   # setze job auf active..
}

Damit kann man die Plattenaktivität je Pool innerhalb von 50s vergleichen. Ist keine Aktivität (Vergleich 2. Zeile und 3. Zeile) kann man den autojob (in /var/web-gui/_log/jobs/jobid.par) auf manuell stellen, alternativ auf active. Den job kann man dann je Minute laufen lassen.
 
Zuletzt bearbeitet:
Ist aber die einzige HDD auf ganz Geizhals mit so niedrigen Werten.
Zum Vergleich, eine WD Red (ebenfalls 5400rpm 1TB) hat 3.3W (Betrieb), 2.3W (Leerlauf)
 
Anmelden, um zu antworten.

Ähnliche Themen

G
Wieviel ZFS steckt in Qnap ZFS ??
Antworten
5
Aufrufe
976
gea
G
Shihatsu
ZFS Pool "verschicken"
Antworten
9
Aufrufe
648
sandreas
S
AG1M
[Kaufberatung] Neuer ZFS Homeserver
Antworten
16
Aufrufe
737
pwnbert
pwnbert
thor17
Ceph Node auf bestehenden ZFS Pools
Antworten
3
Aufrufe
573
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
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