Full SSD-Array/NAS


Kazino43

Recommended Posts

Hallo an alle,

 

nachdem ich eigentlich Unraid nur kurzzeitig testen wollte, hat sich das Ganze doch etwas gezogen. Im Endeffekt gefällt mir das System, relativ einfach zu bedienen, intuitiv und über die GUI einfach anwenderfreundlicher als andere Systeme.

 

Nun läuft mein (eigentlich für 1-2 Monate geplantes) Testsystem bestehend aus irgendwelchen HDDs (teils sogar per USB angebunden, Asche auf mein Haupt) nun schon min. 1 Jahr und der Speicherplatz wird voll. Zudem kann es so nicht weitergehen, da die Daten weder im System durch Parity-Drives noch physikalisch (USB-Stecker ziehen) geschützt sind. War ja auch nur ein Testsystem. :D

 

Speicherplatz brauche ich eigentlich nicht viel, hatte nun zusätzlich zu den Data-Disks eine 500GB Cache SSD und jeweils eine separate 250GB SSD für VM/Docker, um wichtige Docker wie iobroker usw. auf einer separaten SSD zu haben.

 

Aufgrund dessen wollte ich nun 3x4TB +2x2TB SSDs als Daten-Disks und 1x4 TB als Parity-Disk verwenden + jeweils 1x SDD für VM/Docker

 

Eine Cache-Disk ist bei einem Only-SSD-System (zumindest bei 1GB-Ethernet) nicht wirklich mehr vorteilhaft, dass Array ist ja schon schnell.

 

Problem: Nun habe ich den gestrigen Tag mit viel Recherchieren verbracht und bin zum Entschluss gekommen, dass das ganze mit dem Only-SSD-Array nicht so einfach sein wird wie ich gedacht habe.

 

Unraid scheint im btrfs- und xfs-Array kein TRIM zu unterstützten. Ohne TRIM => keine SSDs mit voller Nutzbarkeit => blöde Situation

 

Alternativ habe ich gelesen, dass viele ZFS-Pools benutzen, da dort TRIM unterstützt wird. Das wider rum ist (noch) nicht als Haupt-Array nativ möglich (wann kommt das nächste Update, um diese Funktionalität freizuschalten?). Ich möchte beim Haupt-Array auch nicht mit Plugins und Co. arbeiten, da das System möglichst einfach und simpel aufgebaut werden soll. Wenn man beim Haupt-Array schon Plugins benutzt, kann es bei mir nur problematisch werden. 

 

Bei ZFS-Array hätte ich aber den eigentlich Grund, weswegen ich mich für Unraid entschieden habe, hingeschmissen. Ist es dort irgendwie möglich, das später mögliche ZFS-Haupt-Array auf eine externe HDD zu kopieren, dann das ZFS-Array aufzulösen bzw. weitere SSDs hinzuzufügen und anschließend wieder die Daten von Ext. HDD auf das neue ZFS-Array zu kopieren?

 

Nun meine Frage: Sollte ich einfach noch mit der Low-Cost-Methode weiterfahren (einfach noch restliche HDDs) anschließen, um weiteren Speicherplatz zu haben und auf ein Update zu warten, dass SSD nativ im Haupt-Array TRIM unterstützen bzw. ZFS (mit entsprechendem Autotrim) für das Haupt-Array freigeschaltet wird?

 

Kann man zeitlich einschätzen, wie lange LimeTech noch für die Freischaltung von Trim in btrfs/xfs benötigt bzw. zur nativen Implementierung von ZFS-Pools als Haupt-Array?

 

Eigentlich gibt es keine weiteren Methode, um only-SSDs per Unraid korrekt laufen zu lassen, oder? Eigentlich schade, das Unraid hier relativ weit der Zeit hinterherhingt. SSDs sind nun mal mittlerweile relativ günstig. Braucht man nicht exorbitante Datenmenege zu speichern, gibt es m.M.n. nichts besseres als SSDs im Array und eine große Back-Up HDD für ein externes Langzeit-Backup, vor allem bei den heutigen Stromkosten. 

 

 

 

  • Like 1
Link to comment
30 minutes ago, Kazino43 said:

Kann man zeitlich einschätzen, wie lange LimeTech noch für die Freischaltung von Trim in btrfs/xfs benötigt bzw. zur nativen Implementierung von ZFS-Pools als Haupt-Array?

 

Nein. Limetech hat sich noch nie in ein zeitliches Raster pressen lassen. Wenn 6.12 fertig ist, dann ist es fertig.

 

Link to comment
28 minutes ago, hawihoney said:

 

Nein. Limetech hat sich noch nie in ein zeitliches Raster pressen lassen. Wenn 6.12 fertig ist, dann ist es fertig.

 

Wobei mit 6.12 auch kein Trim im Array mit btrfs oder xfs abzusehen ist. (ich habe davon zumindest nicht sgelesen). Dass ZFS im Array Trim unterstützen würde ist mir ebenfalls noch nicht unter gekommen.

 

Link to comment
3 hours ago, Kazino43 said:

Aufgrund dessen wollte ich nun 3x4TB +2x2TB SSDs als Daten-Disks und 1x4 TB als Parity-Disk verwenden + jeweils 1x SDD für VM/Docker

Weißt Du schon, wie Du die in Summe 8 SSD anbinden willst? SATA, NVME, SAS?

3 hours ago, Kazino43 said:

Unraid scheint im btrfs- und xfs-Array kein TRIM zu unterstützten.

Bisher unterstützt unraid im Array kein Trim.

Dass der Grund dafür BTRFS oder XFS sein soll, sehe ich nicht, da in den Pools ja auch nur die beiden Systeme neu zur Verfügung stehen.

 

3 hours ago, Kazino43 said:

Ohne TRIM => keine SSDs mit voller Nutzbarkeit => blöde Situation

Ohne Trim kann man bei einigen SSD Performanceeinbussen haben. Heutieg Marken SSD haben aber ein GarbageCollectionverhalten, welches da dennoch gute Arbeit leistet. Aber mit Trim wäre es besser.

Auch deshalb ist es sinnvoll SSD ein Pools zu stecken.

 

 

3 hours ago, Kazino43 said:

Alternativ habe ich gelesen, dass viele ZFS-Pools benutzen, da dort TRIM unterstützt wird.

Ein paar leute nutzen ZFS, weil es einige Vorteile hat und diese bei SSD sich nicht ganz so negativ auf den Strombedarf auswirken wie bei Festplatten, die dann länger laufen.

Daß diese Leute es nur wegen Trim machen habe ich noch nirgends gelesen.

 

3 hours ago, Kazino43 said:

Das wider rum ist (noch) nicht als Haupt-Array nativ möglich (wann kommt das nächste Update, um diese Funktionalität freizuschalten?).

Ich habe noch nicht gelesen, daß Trim im Array überhaupt kommen soll. Aber ich habe die Releasenotes zu den neuen RC1 und RC2 auch erst heute morgen überflogen.

Meinem bisherigen Informationsstand nach ist es nur so, daß Trim in den Pools geht.

 

3 hours ago, Kazino43 said:

Ich möchte beim Haupt-Array auch nicht mit Plugins und Co. arbeiten, da das System möglichst einfach und simpel aufgebaut werden soll.

Dann lass das Array doch links liegen (nur mit einem Dummy USB Stick einrichten) und steck alle SSD in entsprechende Pools ab unraid 6.12 (aktuell Rc2) eben auch in ZFS Pools.

3 hours ago, Kazino43 said:

Bei ZFS-Array hätte ich aber den eigentlich Grund, weswegen ich mich für Unraid entschieden habe, hingeschmissen.

Welcher Grund ist denn das überhaupt?

Welchen Vorteil bietet Dir ein SSD Only Array gegenüber SSD Only Pools (ggf. Mehrzahl)?

Ich nutze aktuell in meinen unraidsystemen 4 oder gar mehr SSD, aber eben in Pools. Zu rZeit noch SIngle als xfs und wenn es mehrere zusammen sein sollen als BTRFS, weil ich anders die nicht in Pools kombinieren kann. Sobald ich ZFS halbwegs verstehe werde ich vermutlich die BTRFS Verbünde auf ZFS wechseln.

 

3 hours ago, Kazino43 said:

Ist es dort irgendwie möglich, das später mögliche ZFS-Haupt-Array auf eine externe HDD zu kopieren,

Wenn Du eine groß genuge Festplatte hast kannst Du die Daten auch darauf kopieren.

4+4+4+2+2 TB = 16 TB.  So große (und größere) HDDs gibt es zu kaufen.

Und wnen irgendwann dein unraid Datenschatz größer als die aktuell größten 22TB Festplatten wird, kannst Du ja auch einen Verbund von Festplatten zurück greifen. Ich sichere gerade einen 36TB Nutzdatenverbund auf ein ext. raid5 (Qnap TR-004 mit 4x 12TB Festplatten). Ich sehe irgenbdwie keinen Grund für Deine Bedenken/Frage.

 

3 hours ago, Kazino43 said:

dann das ZFS-Array aufzulösen bzw. weitere SSDs hinzuzufügen und anschließend wieder die Daten von Ext. HDD auf das neue ZFS-Array zu kopieren?

Warum sollte das Transferieren von Daten nicht möglich sein?

Das ist doch das A und O eines NAS und der Freigaben/Shares.

Irgendwie verstehe ich bisher Deine zugrunde liegenden Gedankengänge nicht.

 

3 hours ago, Kazino43 said:

Nun meine Frage: Sollte ich einfach noch mit der Low-Cost-Methode weiterfahren (einfach noch restliche HDDs) anschließen, um weiteren Speicherplatz zu haben und auf ein Update zu warten, dass SSD nativ im Haupt-Array TRIM unterstützen bzw. ZFS (mit entsprechendem Autotrim) für das Haupt-Array freigeschaltet wird?

Hast Du irgendwo gelesen, daß je Trim im Array möglich sein soll?

Das muß ich dann iorgendwie/-wann/-wo übersehen haben.

 

3 hours ago, Kazino43 said:

Kann man zeitlich einschätzen, wie lange LimeTech noch für die Freischaltung von Trim in btrfs/xfs benötigt bzw. zur nativen Implementierung von ZFS-Pools als Haupt-Array?

Im Array sind laut dem, was ich zu RC1 und RC2 gelesen habe nur Single Disk ZFS Konstellationen möglich.

ZFS Raid-Arrays sind für Pools vorgesehen.

Entweder habe ich das komplett überlesen und/oder falsch verstanden oder Du hast vielleicht da einen anderen Wissens-/Vermutungsstand.

 

3 hours ago, Kazino43 said:

Eigentlich gibt es keine weiteren Methode, um only-SSDs per Unraid korrekt laufen zu lassen, oder?

Nimm für SSDs Pools, wie mutmaßlich die Mehrzahl der Leute mit unraid.

 

3 hours ago, Kazino43 said:

Eigentlich schade, das Unraid hier relativ weit der Zeit hinterherhingt.

Unraid war gedacht und ist wohl auch weiterhin hauptsächlich als NAS für große Kapazitäten (und darauf deuten bis zu 28 Datenträger im Array ja hin) vorgesehen.

Ja, man kann es auch mit SSDs machen, aber da Festplatten bei großer Kapazität immer noch preislich attraktiv sind, sind SSD im Array eher zweitrangig.

 

Mal eine ganz kätzerische Frage: Wenn es nur wirklich 'winzige' 16TB Daten sein sollen:

Warum nicht 2x 16TB HDDs (Daten+Parity) und eine große Cache SSD?

Das dürfte billiger sein, bei geschickter Konfiguration auch gleich bis sogar stromsparender als ein durchlaufendes ZFS Raid und weniger Datenträgeranschlüße benötigen.

 

 

3 hours ago, Kazino43 said:

SSDs sind nun mal mittlerweile relativ günstig.

16TB SSD  Kapazität +4Tb SSD Parity schlagen aber dennoch ein größeres Loch in die Kriegskasse als 2x 16TB HDD.

 

3 hours ago, Kazino43 said:

Braucht man nicht exorbitante Datenmenege zu speichern, gibt es m.M.n. nichts besseres als SSDs im Array

16TB sind aber doch schon (noch) recht viel = teuer, wenn es um SSD Kapazität geht, auch, wenn man sie aus 4 und 2TB Einzelkapazitäten zusammen stückelt.

Edited by DataCollector
Typos und Ergänzungen
Link to comment
2 hours ago, Kazino43 said:

Eigentlich gibt es keine weiteren Methode, um only-SSDs per Unraid korrekt laufen zu lassen, oder?

 

Natürlich, im Array (ohne TRIM) und in Pools (ab 6.12 mit dem heißgeliebten TRIM). Ansonsten definiere "korrekt":

 

Quote

Unraid OS Pro supports up to 30 storage devices in the parity-protected array (28 data and 2 parity) and up to 35 named pools, of up to 30 storage devices in the cache pool(s). Additional storage devices can still be utilized directly with other Unraid features such as Virtual Machines or the unassigned devices plugin.

 

Link to comment
1 hour ago, hawihoney said:

 

Das ist falsch. Steht im Announcement:

Jo - sehe ich mit erschrecken!! Wozu das nützlich sein soll steht da leider aber nicht!

Bin gespannt auf die ersten die es versuchen. Eigentlich braucht zfs unbedingt Redundanz damit es sauber und stabil arbeitet. ZFS hat ja eine automatische Fehlererkennung und ohne Redundanz kann es sie nicht reparieren was im Ernstfall (Beschädigung der Metadaten) zu einem Totalausfall des kompletten pools auf der Disk führen kann - man kann die Disk nicht mehr mounten geschweige denn die Daten retten.
Einfach mal googlen.
der CTO von iXsystems sagte so etwas wie "Single Disk ZFS ist so sinnlos, dass es eigentlich schlimmer ist, als ZFS nicht zu verwenden".

 

 

Link to comment
9 minutes ago, Milongero said:

Jo - sehe ich mit erschrecken!! Wozu das nützlich sein soll steht da leider aber nicht!

Wer ZFS nutzen will, wird sich damit wohl etwas genauer beschäftigen müßen. Und dann wird man eben seine Gründe dafür oder dagegen finden.

Meiner (bisher kaum ZFS kundigen) Meinung nach reicht im Array xfs (enc) aus.

 

9 minutes ago, Milongero said:

Eigentlich braucht zfs unbedingt Redundanz damit es sauber und stabil arbeitet.

Stabil im Sinne von vergleichbarem Raid1: klar, dafür opfert man aber eben Kapazität.

Sauber: warum sollte es auf einer einzeklnen Disk unsauber laufen?

 

9 minutes ago, Milongero said:

ZFS hat ja eine automatische Fehlererkennung und ohne Redundanz kann es sie nicht reparieren was im Ernstfall (Beschädigung der Metadaten) zu einem Totalausfall des kompletten pools auf der Disk führen kann

Und dagegen hilft ja die unraid Parität.

Ich sehe deshalb da noch kein Problem.

 

9 minutes ago, Milongero said:

- man kann die Disk nicht mehr mounten geschweige denn die Daten retten.

...wenn man die unraid Parität und die obligatorischen backups komplett ignoriert.

 

9 minutes ago, Milongero said:

Einfach mal googlen.

Einfach mal den normalen Anwendungsfall von unraid im Auge behalten.

Edited by DataCollector
  • Like 1
Link to comment
8 minutes ago, Milongero said:

kompletten pools auf der Disk führen kann - man kann die Disk nicht mehr mounten geschweige denn die Daten retten

Du weißt aber schon wie das UNRAID Array funktioniert?

Das läuft unabhängig vom verwendeten Filesystem.

Bei einer schleichenden Datenveränderung, sollte der (regelmäßige) Parity Check Alarm schlagen (wobei man da leider nicht sieht welche Daten ggfs betroffen sind)

Und bei total Ausfall kann man die Daten durch die Parity wiederherstellen lassen

Link to comment
14 minutes ago, DataCollector said:

Wer ZFS nutzen will, wird sich damit wohl etwas genauer beschäftigen müßen. Und dann wird man eben seine Gründe dafür oder dagegen finden.

Meiner (bisher kaum ZFS kundigen) Meinung nach reicht im Array xfs (enc) aus.

Ist auch meine Meinung

14 minutes ago, DataCollector said:

Stabil im Sinne von vergleichbarem Raid1: klar, dafür opfert man aber eben Kapazität.

Sauber: warum sollte es auf einer einzeklnen Disk unsauber laufen?

Parity (Speicherverlust) hast du im Array doch auch und mit unsauber meine ich Datei Qualität auf dem pool. ZFS kann die erkennen und korrigieren wenn Redundanz vorhanden ist

14 minutes ago, DataCollector said:

 

Und dagegen hilft ja die unraid Parität.

Ich sehe deshalb da noch kein Problem.

Bitte einmal die Funktionsweise der Array Parität mit der Parität innerhalb einen ZFS Pools vergleichen. Die Parität des zpool dient ja gerade zur Datenqualität - während die Array Parität nur der Datensicherheit dient. Man kann mit der Array Parität eine defekte Platte resilvern aber keine Daten im Filesystem reparieren.

14 minutes ago, DataCollector said:

 

...wenn man die unraid Parität und die obligatorischen backups komplett ignoriert.

Parität ist kein Backup sondern dient eigentlich der Verkürzung der Ausfallzeit in einem Produktivsystem - sprich der Server läuft weiter trotz defekter Platte bis der Techniker die Platte tauscht. Während des resilverns kann auch weiter gearbeitet werden. Die Unraid Parität kann nur den letzten Part des resilverns und die Daten auf der Defekten platte sind bis dahin nicht zugänglich. Der Vorteil vom Array ist aber das die Daten auf allen anderen Platten weiterhin zugänglich sind.

Also Parity ist nicht gleich Parity
Bei dem Array was ja auch gerne als Cold Storage bezeichnet wird und in dem die Platten die meiste Zeit im Standby sind frage ich mich ob es überhaupt Sinn macht die in meinen Augen umständliche Array Parität zu nutzen und stattdessen lieber auf eine strategisch sinnvolle Backup Strategie zu setzten

Alleine das preclearen der Array Platten und das dann folgende erste erzeugen der Parität raubt mir schon den letzten nerv. Von der sehr mäßigen Performance beim beschreiben mal ganz abgesehen. 
 

14 minutes ago, DataCollector said:

 

Einfach mal den normalen Anwendungsfall von unraid im Auge behalten.

Jupp hab ich. Cold Storage gehört auf hdd's ins Array und alles was performanter sein soll und trotzdem Sicher - sprich komplette Parität - gehört als Raid konfiguriert in die pools

 

Link to comment
55 minutes ago, Milongero said:

Alleine das preclearen der Array Platten und das dann folgende erste erzeugen der Parität raubt mir schon den letzten nerv.

 

Preclear ist völlig überflüssig. Das macht Unraid selbst.

 

Aber ich denke wir können es an dieser Stelle auch gut sein lassen. Wir drehen uns im Kreis. Du hast ein ganz bestimmtes Einsatz-Szenario skizziert welches Unraid derzeit im Array nicht bietet - aber in den Pools (ab 6.12). Unraid ist wie jedes Produkt ein Angebot. Man hat als potentieller Nutzer dann wie immer mehrere Möglichkeiten. a.) Man zieht weiter b.) Man passt seine Wünsche-Arbeitsweise an das Produkt an c.) Man wartet.

 

In diesem konkreten Fall bringt es noch nicht mal was einen Feature-Request zu initiieren denn was Du schreibst wird sicherlich auf der traditionell von Limetech nicht kommunizierten Roadmap stehen.

 

 

Nachtrag: Die volle ZFS Integration in Unraid wird laut Announcement auf zwei Release ausgedehnt. Eine Mini-Roadmap ohne Terminangabe hätten wir dann schon mal ...

 

Edited by hawihoney
Link to comment

Vielleicht nochmal zur ursprünglichen Frage des Themenstarters:

SSD-Trim - so wie ich das verstehe ist trim im System vorhanden aber speziell fürs Array deaktiviert, da es sich nicht mit der Art wie Unraid die Parity Daten im Array sammelt versteht. D.h. die Parity sammelt die Informationen unterhalb des FS direkt auf der Platte und zählt dabei die Einsen und merkt sich wo sie liegen. Das wird hinterher mit dem Filesystem abgeglichen (Wahrscheinlich Hashwerte).

Bei einem SSD-Trim werden ungenutzte Einsen auf der SSD zu Null umgekippt - davon bekommt aber das Filesystem nichts mit. Wohl aber die Parity Informationen mit dem Schluss das Parity und Filesystem für Unraid nicht mehr zusammenpassen.

In meinen Augen bringt da ein neues Filesystem wenig vielmehr müsste der Prozess der Parity Erzeugung überarbeitet werden damit er auch für SSD-Trim funktioniert. Vielleicht würde es ja schon helfen bei der Erzeugung des Array die Wahl zu haben ob man Parity oder SSD-Trim will. Nur eben beiden nicht zusammen

  • Like 1
Link to comment
1 hour ago, Milongero said:

Parity (Speicherverlust) hast du im Array doch auch

Nur wenn man Parity einrichtet. Aber auch ohne Parity muß es nicht gleich unsauber/defekt sein.

1 hour ago, Milongero said:

und mit unsauber meine ich Datei Qualität auf dem pool.

Sollte zfs auf einer single Disk nicht die selbe Qualität erreichen, die ein normales Filesystem auf einer Singledisk, ist es defekt.

Sollte auf der Disk ein Problem auftreten, würde das problem auftreten, egal ob man fzs oder xfs oder BTRFS oder NTFS oder FAT oder sonst etwas nutzt.

Nur bietet eben ZFS, wie auch BTRFS die Möglichkeit durch zusätzliche Disks (wenn gewünscht) Redundanz zu erreichen. Aber da ZFS im Array eben nur SIngleDisk kann, weil das Array eben nur einzelne Datenträger benutzt bedeutet es nicht, dass die Daten auf einer Disk mit zfs generell unsicherer oder 'unsauberer' sind als die Daten mit xfs.

1 hour ago, Milongero said:

ZFS kann die erkennen und korrigieren wenn Redundanz vorhanden ist

Die redundanz ist bei SingleDIsk egal, weil es sie nicht gibt. Warum ist ZFS als Singel Disk unsauberer als jedes andere Dateisystem, welches eine SIngleDisk verwaltet?

 

1 hour ago, Milongero said:

Bitte einmal die Funktionsweise der Array Parität mit der Parität innerhalb einen ZFS Pools vergleichen.

Das sind zwei komplett unterschiedliche Konzepte und das mit Absicht.

Das unarid Array (egal ob mit oder ohne Parity) benutzt für Dateien imme rnur genau eine Datenfestplatte, damit alle anderen schlafen können. Deshalb ist unraid stromsparender als normaloes Raid (beispielsweise Raid5) weil dort immer alle Disks benötigt werden um eien Datei zu lesen/schreiben.

ZFS benötigt ebenfalls (fast) alle Disks gleichzeitig und ist somit nicht das, was das Ziel un der Nutzen eines unraid Arrays ist. Wenn DU ein permanent laufendes Array haben willst, lege es als Pool an oder überlege ob unraid wirklich das ist, was Du willst.

 

1 hour ago, Milongero said:

Parität ist kein Backup sondern dient eigentlich der Verkürzung der Ausfallzeit in einem Produktivsystem - sprich der Server läuft weiter trotz defekter Platte bis der Techniker die Platte tauscht.

Überlege Dir, ob Du wirklich ein "un"raid haben willst oder ein (zfs)Raid.

 

1 hour ago, Milongero said:

Bei dem Array was ja auch gerne als Cold Storage bezeichnet wird und in dem die Platten die meiste Zeit im Standby sind frage ich mich ob es überhaupt Sinn macht die in meinen Augen umständliche Array Parität zu nutzen und stattdessen lieber auf eine strategisch sinnvolle Backup Strategie zu setzten

Diese Frage kannst Du Dir stellen, für jemand, der möglichst geringe Ausfallzeit haben will, macht es Sinn.

Wer mehr will, ist vielleicht bei unraid nicht richtig aufgehoben. Meine Hardwareraidkontroller schaffen weit mehr, schlucken aber auch weitaus mehr (Strom).

 

1 hour ago, Milongero said:

Alleine das preclearen der Array Platten und das dann folgende erste erzeugen der Parität raubt mir schon den letzten nerv. Von der sehr mäßigen Performance beim beschreiben mal ganz abgesehen. 

Dann lass die Parität doch weg. Dann brauchst Du kein preclear und hast höhere Schreibperformance. Ist doch ganz einfach.

Link to comment

Ich nutzt das Array und die Parity gar nicht - hab eine Platte drin weil ich muß - aber die schläft! Hab je 3 Platten in zwei Pools als ZFS Raidz1 angelegt und bin glücklich.

Es ging ja nur darum über den Sinn von ZFS im Single Disk Array zu diskutieren. Hab ich halt meine Meinung zu und die darf ich wohl haben und du hast Deine - alles Gut.

Zum Thema Stromverbrauch - als ich gerade in Unraid Main geschaut haben waren die drei fetten HDD-Platten aus dem ZFS Raidz1 friedlich am schlummern. Also geht doch mit dem Spindown in einem Raid.

Link to comment
4 minutes ago, Milongero said:

Ich nutzt das Array und die Parity gar nicht - hab eine Platte drin weil ich muß - aber die schläft!

Dann würde ich sogar nur einen USB2.0 Stick nehmen. Der schluckt idle vermutlich sogar noch weniger als eine Platte.

 

4 minutes ago, Milongero said:

Es ging ja nur darum über den Sinn von ZFS im Single Disk Array zu diskutieren. Hab ich halt meine Meinung zu und die darf ich wohl haben und du hast Deine - alles Gut.

Es ging darum daß kazino43 ZFS im Array will, weil er sich davon mutmaßlich Trim verspricht. Und auch wenn ich weiterhin zweifele, daß ZFS im Array Trim ermöglicht ist es Möglich dort einzusetzen und dennoch seh ich nicht, warum es als Singledisk System unsauberer sein soll als ein anderes Dateinsystem auf einer Singledisk.

 

4 minutes ago, Milongero said:

Zum Thema Stromverbrauch - als ich gerade in Unraid Main geschaut haben waren die drei fetten HDD-Platten aus dem ZFS Raidz1 friedlich am schlummern. Also geht doch mit dem Spindown in einem Raid.

Ich zitieremich selber: "Deshalb ist unraid stromsparender als normaloes Raid (beispielsweise Raid5) weil dort immer alle Disks benötigt werden um eien Datei zu lesen/schreiben."

Im Unraidarray liest man aber in der Regel eien datei von einer Disk und wenn man schreibt schreibt man eine Datei nur auf eien Disk und die Parity. im schlimmsten Falls laufen von meinen 26 Festplatten im array also 3 beim Schreiben an.

Ein ZFSraid mit 26 Festplatten braucht wieviele laufende festplatten um eien Datei zu schreiben?

Daß sie idle in den Spindown gehen ist ja nicht ausgeschlossen.

Link to comment
  • 1 year later...

mal was ganz anderes, Wie ist das mit den ZFS Pools, kann man die "im Array" anlegen oder ist das nur als Cache Pool Möglich (was Sinnfrei währe). Oder andersrum was ich in den Nächsten Jahren realisieren will sobald 8TB SSD bei ca 200€ liegen. Ein haufen SSDs im ZFS RaidZ1 Pool und darauf sollen dann die Shares liegen. usätzlich will ich nicht auf mein ZFS Cache Pool verzichten. Sobald der Mover läuft sollen die Daten vom Cache Pool auf den "Array" ZFS Pool zu den "langsamen" Sata SSDs geschoben werden..

 

Aktuell geht mir das auf den Sack. Der Mover muss jeden Tag 1-2 TB Daten aufs Array schieben was nur mit etwa 120M /s passiert das dauert ewig und mir zu lange. Plus ich will von den Mechanischen Platten komplett weg. Durch ständiges Löschen und neu kopieren sind die HDDs dermasen fragmentiert das es einfach keinen Spas mehr macht mit den Daten auf dem Array zu Arbeiten

Link to comment
1 hour ago, Gee1 said:

Wie ist das mit den ZFS Pools, kann man die "im Array" anlegen oder ist das nur als Cache Pool Möglich

 

Für eines der kommenden Release wird erwartet, dass die Grenzen fallen werden. Wenn ich das im Interview mit dem Inhaber richtig gehört habe, dann wird das Array zu einem Pool. Und man wird dann mehrere Array-Pools anlegen können. In diesem Zuge fallen dann auch die Grenzen des Movers. Pool zu Pool wird dann möglich sein.

 

Wie gesagt: Das wurde im Interview angedeutet.

 

 

Edited by hawihoney
  • Like 1
Link to comment
On 3/25/2024 at 3:24 PM, jj1987 said:

Du kannst aber ja mehrere Pools anlegen. Also dann zb einen weiteren Pool für deine SATA SSDs. Und auf den schreibst du dann direkt?!

ja sicher könnte man das irgendwie hindrehen das es passt.. Aber native Unterstützung mit Shares wäre mir schon lieber. Wird sowieso noch gefühlt 5 Jahre dauern bis große SSDs (ab 8 TB) deutlich unter die 200€ Marke fallen

Edited by Gee1
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.