Genau. So mache ich es ja jetzt schon mit PrimoCache unter Windows und bin recht zufrieden. Höre jetzt aber auf damit, den Thread mit meinen Wünschen vollzuspammen.
-
Hallo Gast!
Noch bis zum 20.07. kannst Du an unserer Umfrage zum Hersteller des Jahres teilnehmen! Als Gewinn verlosen wir unter allen Teilnehmern dieses Mal eine Grafikkarte Eurer Wahl für bis zu 1.000 EUR - über eine Teilnahme würden wir uns sehr freuen!
pwnbert
Legende
- Mitglied seit
- 30.10.2014
- Beiträge
- 6.579
ZFS ist halt so ein Datacenter-FS, das eher nicht für solche "Bastellösungen" gedacht ist... das wurde nie für den "sparsamen Heimnutzer" gemacht...
Das ist halt so aufgezogen, dass ein Datenverlust (was ja der Worst Case ist) maximal unwahrscheinlich ist, das alles sehr zuverlässig und robust läuft uuund dass das auch groß skaliert (also viele, viele Datenträger, viele, viele TB). Und natürlich viele Nutzer. Nicht 1, 2 oder 3... sondern vielleicht 100, 1000?
Man will den RAM-Write-Cache ja möglichst schnell leer haben, da der die Daten dort ja wörtlich "in der Schwebe hängen" und wie gesagt, die Datenträger müssen mit dem Schreiben auch nachkommen.
Mit einem entsprechend dicken HDD-Array und ggf. Metadata/Smallblock SSDs hast du kein Geschwindigkeitsproblem.
Die Sache mit dem ARC ist sehr schlau, weil dort ja nur eine Kopie liegt, also nicht sicherheitsrelevant. In der angedachten Verwendung wird eine Datei vielleicht nicht nur von einem Nutzer gelesen, sondern von vielen... da macht das schon Sinn.
Klar, viele Features davon sind auch für "daheim" total interessant und beliebt... aber am Ende ist es doch ein FS, das für einen anderen Zweck als den sparsamen, effizienten Heimuser gemacht wurde (und wird).
Das ist dafür gemacht robust zu sein und von vielen Usern zugleich gequält zu werden ohne massiv an Performance zu verlieren.
Wenn man so nen Cache (SSD?) haben will, ist Unraid einfach das interessantere Konzept.
Aber... wenn du dich spielen willst, such dir halt die CLI-Befehle raus um den RAM-Write-Cache größer zu machen und probier es auf einer Testinstalltion aus. Dafür brauchst ja keine GUI, die paar Zeilen wirst ja noch schaffen (gea hilft dir da bestimmt).
Das ist halt so aufgezogen, dass ein Datenverlust (was ja der Worst Case ist) maximal unwahrscheinlich ist, das alles sehr zuverlässig und robust läuft uuund dass das auch groß skaliert (also viele, viele Datenträger, viele, viele TB). Und natürlich viele Nutzer. Nicht 1, 2 oder 3... sondern vielleicht 100, 1000?
Man will den RAM-Write-Cache ja möglichst schnell leer haben, da der die Daten dort ja wörtlich "in der Schwebe hängen" und wie gesagt, die Datenträger müssen mit dem Schreiben auch nachkommen.
Mit einem entsprechend dicken HDD-Array und ggf. Metadata/Smallblock SSDs hast du kein Geschwindigkeitsproblem.
Die Sache mit dem ARC ist sehr schlau, weil dort ja nur eine Kopie liegt, also nicht sicherheitsrelevant. In der angedachten Verwendung wird eine Datei vielleicht nicht nur von einem Nutzer gelesen, sondern von vielen... da macht das schon Sinn.
Klar, viele Features davon sind auch für "daheim" total interessant und beliebt... aber am Ende ist es doch ein FS, das für einen anderen Zweck als den sparsamen, effizienten Heimuser gemacht wurde (und wird).
Das ist dafür gemacht robust zu sein und von vielen Usern zugleich gequält zu werden ohne massiv an Performance zu verlieren.
Wenn man so nen Cache (SSD?) haben will, ist Unraid einfach das interessantere Konzept.
Aber... wenn du dich spielen willst, such dir halt die CLI-Befehle raus um den RAM-Write-Cache größer zu machen und probier es auf einer Testinstalltion aus. Dafür brauchst ja keine GUI, die paar Zeilen wirst ja noch schaffen (gea hilft dir da bestimmt).
Nehmen wir das Beispiel mit 64GB RAM. Ein 64bit OS möchte 4GB, ZFS wird ohne Lesecache mit mechanischen Platten sehr langsam, geben wir also mindestens 8 GB Lesecache (default wäre 50% also ca 30GB. Damit wären die meisten random reads aus dem RAM geliefert worden).
Wir könnten also mit starken Abstrichen beim Lesen ca 50 GB Write Ramcache haben. Ist der halbvoll muss weggeschrieben werden, der sollte ja nie volllaufen (Pool muss dabei deutlich schneller als LAN sein, sonst läuft der Cache immer voll). Nutzbar ist also ca 25 GB pro single User. Nicht so üppig. Hat man mehrere aktive User, teilt sich das auf. Stürzt der Rechner ab ist der komplette Inhalt des Schreibcaches one sync verloren.
Eine Writecache SSD unter Unraid hat das gleiche Problem, ist aber viel langsamer als RAM Cache und verliert Daten wenn der Rechner beim Schreiben ohne CoW abstützt. Ausweg: ZFS unter Unraid. (Zurück an Anfang).
ZFS macht das schon richtig per defaults oder als Hybrid Pool mit special vdev. Ein RAM Schreibcache von ein paar GB ist vollkommen ausreichend und kleine, langsame io zu vermeiden auch bei viel Last und vielen Nutzern.
Macht man nichts, hat man mit 64GB RAM ca 30GB Lesecache und 6GB Schreibcache, ideal für fast alle Fälle.
Wir könnten also mit starken Abstrichen beim Lesen ca 50 GB Write Ramcache haben. Ist der halbvoll muss weggeschrieben werden, der sollte ja nie volllaufen (Pool muss dabei deutlich schneller als LAN sein, sonst läuft der Cache immer voll). Nutzbar ist also ca 25 GB pro single User. Nicht so üppig. Hat man mehrere aktive User, teilt sich das auf. Stürzt der Rechner ab ist der komplette Inhalt des Schreibcaches one sync verloren.
Eine Writecache SSD unter Unraid hat das gleiche Problem, ist aber viel langsamer als RAM Cache und verliert Daten wenn der Rechner beim Schreiben ohne CoW abstützt. Ausweg: ZFS unter Unraid. (Zurück an Anfang).
ZFS macht das schon richtig per defaults oder als Hybrid Pool mit special vdev. Ein RAM Schreibcache von ein paar GB ist vollkommen ausreichend und kleine, langsame io zu vermeiden auch bei viel Last und vielen Nutzern.
Macht man nichts, hat man mit 64GB RAM ca 30GB Lesecache und 6GB Schreibcache, ideal für fast alle Fälle.
Zuletzt bearbeitet:
Und will man auch unter Unraid CoW Absturzsicherheit für atomare Schreibvorgänge nimmt man da auch gerne ZFS für Daten und Cache. Man kann allenfalls ein ZFS Raid Array vermeiden um diese mit single Disk Pools .schlafen zu lassen. ZFS Redundanz gäbe halt mehr Performance und Echtzeit Raid Protection statt Unraid "Backup on demand"
besterino
Legende
Für schnelle sequentielle writes muss man halt einfach die nackte Performance der physischen ZFS-Datenträger so hoch schrauben, dass sie (deutlich) über der Netzwerkperformance hängt. Alles andere ist Gefrickel zu Lasten der Datenintegrität (oder wenns ganz blöd läuft, sogar der ZFS-Performance an anderer Stelle). Wobei meiner Meinung nach ZFS eh kein Geschwindigkeits-Performance-Wunder ist (designseitig wurden da bewusst - und zurecht! - Entscheidungen zu Gunsten der Datensicherheit/-Integrität und zu Lasten der Geschwindigkeit getroffen).
Da ist selbst NTFS deutlich flotter…
Da ist selbst NTFS deutlich flotter…
Wenn man so in die aktuelle Landschaft schaut, ist ZSF ja durchaus salonfähig geworden. Wird ja auch an allen Ecken und Ende besprochen 
... Was mir aktuell besonders auffällt, ist, dass ECC in der Betrachtung doch arg ausgeblendet wird. Eine Günstig-Kiste nach der anderen. 3,4, 6 NVME. Alles zum "Spotpreis".
Ist ECC mittlerweile nur noch was für Geeks? Oder bleibt das Thema, wie bisher, relevant?
... Was mir aktuell besonders auffällt, ist, dass ECC in der Betrachtung doch arg ausgeblendet wird. Eine Günstig-Kiste nach der anderen. 3,4, 6 NVME. Alles zum "Spotpreis". Ist ECC mittlerweile nur noch was für Geeks? Oder bleibt das Thema, wie bisher, relevant?
layerbreak
Enthusiast
- Mitglied seit
- 30.12.2010
- Beiträge
- 593
Danke dir. Wenn ich soweit bin, darf ich diesbezüglich auf dich zurückkommen, wenn ich Omnios unter Proxmox nicht zum Laufen bringe?
Nur ESXI 8.0 Update 3e ist wieder free. Folgeversionen hat Broadcom anscheinend nicht als Free angekündigt und auch nicht zugesagt.
Es ist einfach wie früher - hat man sich einmal getrennt, aus Gründen welch auch immer, sollte man nicht mehr zurückschauen und die Beziehung abhaken.
Dein napp-it pro Home gibt es aber immer noch und du entwickelst es weiter?
Ich bin kein Profi in diesem Thema, aber ECC ist für mich schon seit Solaris10 Pflicht. Und ich hab seither noch nie Daten verloren, weil sie "faulig" waren.
Sun hat in ZFS alles eingebaut damit keine Datenverluste auftreten -
bis auf human error, Softwarebug oder Hardwareprobleme.
Nicht entdeckte RAM Fehler (ohne ECC) und damit einhergehende Datenverluste sind Hardwareprobleme.
btw
Ich bleibe vorerst bei ESXi 8 mit OmniOS, habe Proxmox aber in der engeren Auswahl.
Auch Windows ist überzeugend sobald ZFS released ist.
Napp-it home ist als se (Solaris edition) und neu als cs (client server, alle OS) verfügbar.
Melde Dich dann einfach
Beitrag automatisch zusammengeführt:
Yepp. So sehe ich das auch. Dieses Problem bleibt halt bestehen und sollte, wenn einem die Daten wichtig sind, weiterhin mit ECC adressiert werden. Merci
pwnbert
Legende
- Mitglied seit
- 30.10.2014
- Beiträge
- 6.579
Ja, wobei man sagen muss, dass ECC im Privatbereich schon die letzten >25 Jahre kein Thema ist.
Fehler und Probleme kommen zwar vor, verhältnismäßig aber in eher kleinem Umfang.
Die Endgeräte, auf denen mit den Daten "gearbeitet" wird, haben zu 99% kein ECC (die ganzen Mobile Geräte eher zu 100%), da ist das schon die absolute Seltenheit.
Dafür "passiert" eigentlich relativ wenig.
Ist halt so ne Konzernsache, dass man ECC dem hochpreisigen Enterprise-Markt vorbehält. Mehr kosten tut der Kram ja eigentlich nicht.
Man sieht doch super z.B. bei AMD, dass ECC überhaupt kein Problem ist, auch mit UDIMM und Consumer-Hardware, wäre es verbreiteter, wären die Module auch billiger (bzw. waren die zeitweise schon halbwegs preiswert zu haben). Da wurde bewusst dem Cezanne das ECC "genommen" und nur mit dem teureren (bzw. retail nicht erhältlichem) Cezanne "-Pro" CPUs ermöglicht.
Bei Intel nicht anders, die CPU selbst können/könnten es, die Sockel ebenso, das ist eine reine Managemententscheidung und künstliche Beschneidung, dass ECC nicht breiter verfügbar bzw. üblich ist.
Ich denke, dass diese ganzen "home friendly" Systeme auch ohne ECC bleiben werden (QNAP und Syno NAS etc. sind ja auch alle ohne ECC, zumindest die günstigeren Modelle).
Die Marketingentscheidung ECC den teureren Chipsätzen/CPUs vorzubehalten ist nachvollziehbar aber übel.
Gemein ist halt dass Datenfehler wegen Ramfehlern ohne ECC zu nicht entdeck- oder korrigierbaren Fehlern führt, selbst mit ZFS. Dass Ramfehler nur sehr selten sind und teils keine Daten beschädigen ist ein geringer Trost.
Wartet man lange genug vor allem mit mehr RAM so wird aus der geringen statistischen Wahrscheinlichkeit ein Fehler der zu 100% auftreten wird. Das lange genug kann halt 5s sein oder 1 Jahr.
Gemein ist halt dass Datenfehler wegen Ramfehlern ohne ECC zu nicht entdeck- oder korrigierbaren Fehlern führt, selbst mit ZFS. Dass Ramfehler nur sehr selten sind und teils keine Daten beschädigen ist ein geringer Trost.
Wartet man lange genug vor allem mit mehr RAM so wird aus der geringen statistischen Wahrscheinlichkeit ein Fehler der zu 100% auftreten wird. Das lange genug kann halt 5s sein oder 1 Jahr.
Vielleicht mache ich das dann schon immer falsch ... finde aber ZFS im Homeserversetting schon sehr fesch, gerade mit Proxmox zusammen. Aber auch da gehen ja die Meinungen, wie man es "richtig" macht sehr weit auseinander. Mein System ist keep it simple, zwei schnelle NVME-SSDs als ZFS-RAID 1 mit Proxmox und keine Trennung von Bootlaufwerk / VM / Daten. Damit lässt sich auch ein schön sparsames System bauen. Was ich mir davon verspreche?
- die praktischen Funktionen von ZFS (z.B. Snapshot, Replication etc)
- etwas Sicherheit gegen Bitrot
- trotzdem ausreichend Geschwindigkeit
Oder liege ich mit so einem Setup daneben?
Kann man schon so machen.
Wird aus welchem Grund auch immer eine Neuinstallation fällig, gibt es halt ein hohes Risiko Daten zu verlieren weil der Pool neu angelegt wird. Jeder der viel mit Storage zu tun hat, wird daher eher dazu raten, eine kleine OS disk zu nehmen und einen extra Pool für VMs und Daten. Das erlaubt auch das physische Tauschen eines Datenpools.
Wird aus welchem Grund auch immer eine Neuinstallation fällig, gibt es halt ein hohes Risiko Daten zu verlieren weil der Pool neu angelegt wird. Jeder der viel mit Storage zu tun hat, wird daher eher dazu raten, eine kleine OS disk zu nehmen und einen extra Pool für VMs und Daten. Das erlaubt auch das physische Tauschen eines Datenpools.
besterino
Legende
Kein Setup ist grds. „Daneben“. Ich persönlich trenne lieber OS und Pool Datenträger, weil ich gerne die Flexibilität habe, den Pool mal einfach „woanders“ einzuhängen (sei es Software- oder Hardwaremäßig). Auch fahre ich andere Redundanzlevel: bei den OS Datenträgern nehm ich (das ZFS Pendant zu) Raid1, beim Pool je nachdem RaidZ(2), simple (Raid0) oder oder oder. Hängt aber extrem vom gewünschten Speicherplatz und dessen Performance ab.
