Frage zu TrueNAS

[Clapinoson]

Hi,

ich habe seit einiger Zeit TrueNAS am Laufen und bin eigentlich ziemlich zufrieden damit. Allerdings kommt es hin und wieder zu Performance-Einbrüchen bei Kopiervorgängen, die ich mir so nicht wirklich erklären kann. Meistens hilft dann ein Neustart. Ist ein etwas älterer Intel CPU mit 3,2 GHZ und 4 Kernen und 32 GB RAM.

Soweit ich das gesehen habe, lief auch kein Scrubs im Hintergrund während des Kopiervorgangs. Wo und wie könnte ich mit der Fehlersuche anfangen, Hardware scheint in Ordnung zu sein, RAM habe ich getestet mittels MEMTEST, die Festplatten sind neu und auch noch gut laut S.M.A.R.T. Test.

Vielleicht hat jemand mehr Erfahrung als ich mit TrueNAS oder schon ähnliche Probleme gehabt. Würde mich über gute Ratschläge wirklich freuen.

Grüße

 

[madmax2010]

liste doch mal alle verbaute hardware auf und beschreib die Performance Einbrüche.
und sag uns wie zfs sonst so konfiguriert ist.
wie kopierst du? ueber welches medium?

 

[Nordwind2000]

Samba als Protokoll?
Hast du die Samba-Verschlüsselung aktiv bzw. die Protokollierung? Kann unter Umständen zu Einbrüchen führen.

 

[Clapinoson]

Ah, sorry genau da war doch noch was^^

Hardware
----------------------------------
XEON E3 1230 Quadcore mit 3.2 GHz (2013)
32 GB NON-ECC 1600 DDR3
10 GBit LAN Mellanox LWL
250 GB SSD Samsung 850 Pro (System)


----------------------------------
ZFS Pool 1
2x 4 TB WD RED 2018
Kompressionslevel 1.05
No Deduplicaten

----------------------------------
ZFS Pool 2
2x 10 TB WD GOLD 2021
Kompressionslevel 1.05
No Deduplicaten


Kein L2ARC und kopiert wird über Win10 von den Samba Freigaben. Normalerweise läuft das System stabil und das Kopieren geht mit ~ 280 MB/s. Mein Win10 Client hat nur NVME Speicher, also sowohl System als auch Datenablage und eine 2.5 GB/s NIC.

Nur nach einer längeren Zeit, geht der Durchsatz runter und ein Neustart wird durchgeführt, danach läuft wieder alles optimal und so wie gewohnt.

Wo könnte das Problem liegen, ach ja IPERF3 liefert den idiealen Durchsatz... wobei mir fällt gerade ein das ich es mit IPERF, wenn das Problem auftritt, noch nicht getestet habe... das wäre zur Fehlereingrenzung vielleicht noch gut zu wissen, ob es vielleicht irgendwie an den Platten läge...

Ich hoffe die Infos zur Hardware und Konfiguration sind ausreichend, ansonsten liefer ich gerne noch was nach.

Ergänzung (16. Juli 2022)

Samba als Protokoll?
Hast du die Samba-Verschlüsselung aktiv bzw. die Protokollierung? Kann unter Umständen zu Einbrüchen führen.

Ich glaub nicht, also ich finde die Option gerade nicht, siehe bitte den Screenshot dazu.

Kann es sein, dass Encryaption bei Samba, per Parameter separat aktiviert werden muss, weil dann ist es definitiv nicht an.

 

[ssh]

Du schreibst nicht einmal wie groß diese Einbrüche sind, würde das länger beobachten und mehrfach testen (über eine Woche)

 

[Clapinoson]

Die Einbrüche erhalte ich sowohl im Down- als auch Upload und statt die 280 MB/s bekomme ich dann so um die 140 MB/s.

Wie gesagt, es passiert immer wieder nach einigen Monaten und nach einem Neustart ist alles wieder gut.

Ich hatte auch gehofft, Tipps zu bekommen, wo ich nachsehen kann oder welche Befehle ich in die Console eingebe, wenn es wieder auftritt, also um den Fehler weiter einzugrenzen oder auch zu lokalisieren.

 

[Clapinoson]

[...] nicht einmal [...]

Wenn das so marginal und für mich unbedeutend wäre, würde ich dann hier eine Anfrage stellen oder was genau meinst du damit?

 

[ssh]

War viele Jahre in einem Systemhaus tätig und du glaubst nicht welches Fass Kunden wegen einer Mücke aufmachen weils das "größte Problem aller Zeiten" ist, das sofort gelöst werden muss.
Schau dir die event logs an, vielleicht läuft da was im Speicher voll.

 

[Clapinoson]

Nichts für ungut, stehe zur Zeit etwas unter Stress ;-)

Danke für den Tipp, Speicher ist auch ein gutes Stichwort, der ZFS (ARC) bzw. die Speicherauslastung ist ziemlich ausgelastet nach den 2 - 3 Monaten, dann wenn dieses Problemchen auftritt. Ich habe gelesen das dies normal sei, weil ZFS den Speicher reserviert. Ob das der Grund für den Einbruch ist, wäre auch eine Frage von mir gewesen?

Und ja, so ganz unwichtig ist das für mich nicht, auch wenn das nicht Überlebens-entscheidend ist, aber man hat doch etwas in Hardware und Strom investiert, und da sollte dann schon alles passen ;-)

 

[Clapinoson]

Das Syslog muss ich erst noch suchen, hier sind ein paar Screenshots von den grafischen Berichten.

 

[snaxilian]

Sind die Einbrüche beim Memory und ARC wenn die Probleme passieren oder sind das Reboots?

TrueNAS

DAS ist ein Markenname und kein Produkt. Redest du von CORE oder SCALE?

Die Halbierung würde mich in die Richtung schicken, dass er die Daten nicht sauber von beiden HDDs je Pool bekommt sondern nur auf eine...

Doku lesen ist immer hilfreich: https://www.truenas.com/docs/core/uireference/reportinggraphs/
Was sagen denn die diversen Graphs zu dein einzelnen HDDs wenn die Probleme auftreten? Sieht man da etwas und falls ja: Ist es immer die gleiche HDD, die auffällig ist?

 

[Clapinoson]

Sind die Einbrüche beim Memory und ARC wenn die Probleme passieren oder sind das Reboots?

Es ist TrueNAS CORE, Version 12.

Bei den Einbrüchen im Graphen, handelt es sich um Reboots.

Bei den HDD's sieht man direkt nichts, also dort ist mir jetzt nichts Außergewöhnliches aufgefallen. Ich werde mal versuchen, herauszufinden, wie ich unter Truenas die HDD's benchmarken kann.

Allerdings denke ich rein subjektiv nicht, dass es die Pools oder HDD's das Problem verursachen. Wie ist das eigentlich mit dem Cache (ARC), werden die Daten nach dem diese übertragen wurden auf die Platten geschrieben oder während der Übertragung, ich glaube nämlich, das es etwas mit dem Chache zu tun hat, kann aber leider meine Vermutung weder beweisen noch testen, da fehlt mir gerade noch das Wissen dazu.

Ergänzung (17. Juli 2022)

root@truenas[~]# diskinfo -t /dev/ada1
/dev/ada1
        512             # sectorsize
        10000831348736  # mediasize in bytes (9.1T)
        19532873728     # mediasize in sectors
        4096            # stripesize
        0               # stripeoffset
        19377850        # Cylinders according to firmware.
        16              # Heads according to firmware.
        63              # Sectors according to firmware.
        WDC WD102KRYZ-01A5AB0   # Disk descr.
        VCJ46WTP        # Disk ident.
        id1,enc@n3061686369656d30/type@0/slot@2/elmdesc@Slot_01 # Physical path
        No              # TRIM/UNMAP support
        7200            # Rotation rate in RPM
        Not_Zoned       # Zone Mode

Seek times:
        Full stroke:      250 iter in   4.746339 sec =   18.985 msec
        Half stroke:      250 iter in   3.462222 sec =   13.849 msec
        Quarter stroke:   500 iter in   5.609678 sec =   11.219 msec
        Short forward:    400 iter in   1.638980 sec =    4.097 msec
        Short backward:   400 iter in   2.621410 sec =    6.554 msec
        Seq outer:       2048 iter in   0.077521 sec =    0.038 msec
        Seq inner:       2048 iter in   0.140612 sec =    0.069 msec

Transfer rates:
        outside:       102400 kbytes in   0.378588 sec =   270479 kbytes/sec
        middle:        102400 kbytes in   0.448702 sec =   228214 kbytes/sec
        inside:        102400 kbytes in   0.767902 sec =   133350 kbytes/sec

root@truenas[~]# diskinfo -t /dev/ada0
/dev/ada0
        512             # sectorsize
        10000831348736  # mediasize in bytes (9.1T)
        19532873728     # mediasize in sectors
        4096            # stripesize
        0               # stripeoffset
        19377850        # Cylinders according to firmware.
        16              # Heads according to firmware.
        63              # Sectors according to firmware.
        WDC WD102KRYZ-01A5AB0   # Disk descr.
        VCJ4HB4P        # Disk ident.
        id1,enc@n3061686369656d30/type@0/slot@1/elmdesc@Slot_00 # Physical path
        No              # TRIM/UNMAP support
        7200            # Rotation rate in RPM
        Not_Zoned       # Zone Mode

Seek times:
        Full stroke:      250 iter in   4.736249 sec =   18.945 msec
        Half stroke:      250 iter in   3.441130 sec =   13.765 msec
        Quarter stroke:   500 iter in   5.532694 sec =   11.065 msec
        Short forward:    400 iter in   0.976248 sec =    2.441 msec
        Short backward:   400 iter in   1.974928 sec =    4.937 msec
        Seq outer:       2048 iter in   0.072904 sec =    0.036 msec
        Seq inner:       2048 iter in   0.150423 sec =    0.073 msec

Transfer rates:
        outside:       102400 kbytes in   0.395896 sec =   258654 kbytes/sec
        middle:        102400 kbytes in   0.472433 sec =   216750 kbytes/sec
        inside:        102400 kbytes in   0.813610 sec =   125859 kbytes/sec

root@truenas[~]# diskinfo -t /dev/ada0
/dev/ada0
        512             # sectorsize
        10000831348736  # mediasize in bytes (9.1T)
        19532873728     # mediasize in sectors
        4096            # stripesize
        0               # stripeoffset
        19377850        # Cylinders according to firmware.
        16              # Heads according to firmware.
        63              # Sectors according to firmware.
        WDC WD102KRYZ-01A5AB0   # Disk descr.
        VCJ4HB4P        # Disk ident.
        id1,enc@n3061686369656d30/type@0/slot@1/elmdesc@Slot_00 # Physical path
        No              # TRIM/UNMAP support
        7200            # Rotation rate in RPM
        Not_Zoned       # Zone Mode

Seek times:
        Full stroke:      250 iter in   4.706663 sec =   18.827 msec
        Half stroke:      250 iter in   3.449569 sec =   13.798 msec
        Quarter stroke:   500 iter in   3.777810 sec =    7.556 msec
        Short forward:    400 iter in   0.805720 sec =    2.014 msec
        Short backward:   400 iter in   0.859965 sec =    2.150 msec
        Seq outer:       2048 iter in   0.132934 sec =    0.065 msec
        Seq inner:       2048 iter in   0.131939 sec =    0.064 msec

Transfer rates:
        outside:       102400 kbytes in   0.420916 sec =   243279 kbytes/sec
        middle:        102400 kbytes in   0.475851 sec =   215193 kbytes/sec
        inside:        102400 kbytes in   0.808277 sec =   126689 kbytes/sec

root@truenas[~]# diskinfo -t /dev/ada1
/dev/ada1
        512             # sectorsize
        10000831348736  # mediasize in bytes (9.1T)
        19532873728     # mediasize in sectors
        4096            # stripesize
        0               # stripeoffset
        19377850        # Cylinders according to firmware.
        16              # Heads according to firmware.
        63              # Sectors according to firmware.
        WDC WD102KRYZ-01A5AB0   # Disk descr.
        VCJ46WTP        # Disk ident.
        id1,enc@n3061686369656d30/type@0/slot@2/elmdesc@Slot_01 # Physical path
        No              # TRIM/UNMAP support
        7200            # Rotation rate in RPM
        Not_Zoned       # Zone Mode

Seek times:
        Full stroke:      250 iter in   4.739219 sec =   18.957 msec
        Half stroke:      250 iter in   3.477210 sec =   13.909 msec
        Quarter stroke:   500 iter in   4.256569 sec =    8.513 msec
        Short forward:    400 iter in   0.826610 sec =    2.067 msec
        Short backward:   400 iter in   0.823626 sec =    2.059 msec
        Seq outer:       2048 iter in   0.076537 sec =    0.037 msec
        Seq inner:       2048 iter in   0.150468 sec =    0.073 msec

Transfer rates:
        outside:       102400 kbytes in   0.368029 sec =   278239 kbytes/sec
        middle:        102400 kbytes in   0.451376 sec =   226862 kbytes/sec
        inside:        102400 kbytes in   0.769620 sec =   133053 kbytes/sec

root@truenas[~]# diskinfo -t /dev/ada3
/dev/ada3
        512             # sectorsize
        4000787030016   # mediasize in bytes (3.6T)
        7814037168      # mediasize in sectors
        4096            # stripesize
        0               # stripeoffset
        7752021         # Cylinders according to firmware.
        16              # Heads according to firmware.
        63              # Sectors according to firmware.
        WDC WD40EZRZ-00GXCB0    # Disk descr.
        WD-WCC7K1DT39XU # Disk ident.
        id1,enc@n3061686369656d30/type@0/slot@4/elmdesc@Slot_03 # Physical path
        No              # TRIM/UNMAP support
        5400            # Rotation rate in RPM
        Not_Zoned       # Zone Mode

Seek times:
        Full stroke:      250 iter in   7.263068 sec =   29.052 msec
        Half stroke:      250 iter in   5.181355 sec =   20.725 msec
        Quarter stroke:   500 iter in   8.005192 sec =   16.010 msec
        Short forward:    400 iter in   3.450856 sec =    8.627 msec
        Short backward:   400 iter in   1.980941 sec =    4.952 msec
        Seq outer:       2048 iter in   0.264439 sec =    0.129 msec
        Seq inner:       2048 iter in   0.171052 sec =    0.084 msec

Transfer rates:
        outside:       102400 kbytes in   0.607114 sec =   168667 kbytes/sec
        middle:        102400 kbytes in   0.671513 sec =   152491 kbytes/sec
        inside:        102400 kbytes in   1.269531 sec =    80660 kbytes/sec

root@truenas[~]# diskinfo -t /dev/ada2
/dev/ada2
        512             # sectorsize
        4000787030016   # mediasize in bytes (3.6T)
        7814037168      # mediasize in sectors
        4096            # stripesize
        0               # stripeoffset
        7752021         # Cylinders according to firmware.
        16              # Heads according to firmware.
        63              # Sectors according to firmware.
        WDC WD40EZRZ-00GXCB0    # Disk descr.
        WD-WCC7K6RLF34K # Disk ident.
        id1,enc@n3061686369656d30/type@0/slot@3/elmdesc@Slot_02 # Physical path
        No              # TRIM/UNMAP support
        5400            # Rotation rate in RPM
        Not_Zoned       # Zone Mode

Seek times:
        Full stroke:      250 iter in   6.785191 sec =   27.141 msec
        Half stroke:      250 iter in   4.692433 sec =   18.770 msec
        Quarter stroke:   500 iter in   7.962148 sec =   15.924 msec
        Short forward:    400 iter in   3.579203 sec =    8.948 msec
        Short backward:   400 iter in   1.751124 sec =    4.378 msec
        Seq outer:       2048 iter in   0.165603 sec =    0.081 msec
        Seq inner:       2048 iter in   0.158737 sec =    0.078 msec

Transfer rates:
        outside:       102400 kbytes in   0.593012 sec =   172678 kbytes/sec
        middle:        102400 kbytes in   0.676915 sec =   151275 kbytes/sec
        inside:        102400 kbytes in   1.150115 sec =    89035 kbytes/sec

root@truenas[~]#

Also, die beiden WD Gold sind tatsächlich nicht ganz symmetrisch, was die Geschwindigkeit angeht, aber mit über 250 MB/s liegen diese immer noch über der Geschwindigkeit, welche nach dem Einbruch erhalten wird.

 

[snaxilian]

Die Graphen für Disk Busy, Disk Latency, Disk Operations detailed, Pending I/O und Disk I/O sind also identisch bei den jeweils betroffenen HDDs wenn die Drops auftreten?

Welcher compression Algorithmus ist bei deinen Datasets eingestellt? lz4 oder ein anderer?
Laufen zum Zeitpunkt der Drops irgendwelche cron jobs, periodic snapshot tasks, rsync tasks, cloud sync tasks oder replication tasks?

Es ist TrueNAS CORE, Version 12.

Dann solltest du mal mindestens auf TrueNAS CORE 12.0-U8.1 aktualisieren, gab da doch den ein oder anderen Fix.

Wie ist das eigentlich mit dem Cache (ARC) [...] da fehlt mir gerade noch das Wissen dazu.

Den Link zur Doku habe ich dir ja weiter oben bereits. Es hilft, diesen Abschnitt von dir aus der Thematik komplett raus zu nehmen wenn du herausfindest, wofür die Abkürzung ARC steht und dann sollte sich erklären ob und was dieser mit dem schreiben von Daten zu tun hat.

Grundlegend: Write Speed auf einen Pool mit mirrored VDEVs ist (pro VDEV) limitiert auf die Geschwindigkeit einer einzelnen HDD. Read Speed hingegen steigt mit jeder HDD. Höhere (angezeigte) Werte sind erst einmal nix anderes als flüchtige im RAM angekommene Daten durch die 2,5 GBit/s NIC die dann weg geschrieben werden müssen. Nein, das ist dann kein Write Cache im RAM auch wenn das für den Laien das Gleiche sein mag.

Zwar schon knapp 3 Jahre alt aber in weiten Teilen immer noch gültig als Vergleich und Einstieg: https://calomel.org/zfs_raid_speed_capacity.html

Das Syslog muss ich erst noch suchen

Wie bei den meisten Unix/Linux Systemen sollten diese unter /var/log/ zu finden sein.

 

[Clapinoson]

Die Graphen für Disk Busy, Disk Latency, Disk Operations detailed, Pending I/O und Disk I/O sind also identisch bei den jeweils betroffenen HDDs wenn die Drops auftreten?

Es sieht zumindest so aus, hab noch mal Screenshots gemacht, vielleicht könntest du da auch noch mal drüber sehen?

Welcher compression Algorithmus ist bei deinen Datasets eingestellt? lz4 oder ein anderer?
Laufen zum Zeitpunkt der Drops irgendwelche cron jobs, periodic snapshot tasks, rsync tasks, cloud sync tasks oder replication tasks?

Inherits (lz4), So weit ich weiß lief nichts zu dem Zeitpunkt nebenbei. Außer Scrubs ist auch nichts konfiguriert in der Hinsicht.

Also mein System sagt, es sei auf dem aktuellen Stand, letztes Update war glaube ich im April oder Mai.

Sollte ich auf die Version 13 wechseln, wäre das sinnvoll und mit kleinem Risiko verbunden?

Ich lese mich noch zu deinen Links ein und melde mich wieder...

 

[snaxilian]

Die vier hohen Peaks beim lesen werden vermutlich Scrubs sein nehme ich an? Generell sind jetzt keine größeren Schreiboperationen ersichtlich.

Mit TrueNAS Core 13 würde ich bis zum U2 warten, ansonsten mal Release Notes lesen. Wenn die known issues einem egal sind oder nicht betreffen, kann man ggf. auch schon updaten. So oder so hat man natürlich selbstverständlich Backups der Daten um im Fehlerfall zurück gehen zu können, nicht wahr?^^

Zum Thema Benchmarks siehe mein letzter Link, wenn du parallel noch sehen willst wie viel Durchsatz du hast dann sind die Befehle "zpool iostat" bzw. "iostat" für einzelne Disks interessant

 

[Clapinoson]

Mit TrueNAS Core 13 würde ich bis zum U2 warten

Ich denke auch, dass das eine gute Idee ist.

Die vier hohen Peaks beim lesen werden vermutlich Scrubs sein nehme ich an? Generell sind jetzt keine größeren Schreiboperationen ersichtlich.

Jap.

Ich denke fast, dass ich fürs schnelle lesen/schreiben von Daten, am besten einen reinen SSD Pool bauen werde, muss auch nicht groß sein, 1 TB würde mir da definitiv reichen. Die mechanischen Platten sind denke ich, hier das größere Problem.

Weil ich auch noch mal einige Tests mit sehr großen Datenmengen gefahren bin, hochladen funktioniert relativ gut, fast durchgehend mit 2,5 GB/s, beim Downloaden gibt es ständig Drops in der Geschwindigkeit. Den ARC habe ich jetzt testweise mittels tuneables auf 26 GB limitiert, um dem System noch etwas Luft einzuräumen.

Alles, was nicht direkt in den RAM geladen wird, von einer schnellen Quelle wie z. B. SSD, verursacht das Problem bzw. Bottleneck. Es war einfach Wunschdenken von mir, dass die WD Gold eine schnelle und konstante Geschwindigkeit halten könne, also bei 2,5 GB/s, und zukünftig von 10 GB/s bin ich ja noch ganz weit entfernt, wenn das jetzt noch nicht mal richtig funktioniert. (Bin ein wenig enttäuscht)

Was denkst du, könnte ich mit meiner Vermutung richtig liegen und wäre ein SSD Pool eine Möglichkeit?

Hier noch ein paar Tests:

root@truenas[~]# zpool iostat
                capacity     operations     bandwidth
pool          alloc   free   read  write   read  write
------------  -----  -----  -----  -----  -----  -----
RaidStorage   2.30T  1.33T      1     23  17.2K   418K
RaidStorage2  1.18T  7.90T     49    104  9.19M  39.3M (WD Gold)
boot-pool     2.41G   214G      0      0  8.14K    498
------------  -----  -----  -----  -----  -----  -----

root@truenas[~]# iostat ada4
       tty            ada4             cpu
 tin  tout  KB/t tps  MB/s  us ni sy in id
   0     4 11.14   1  0.01   0  0  3  1 95
 
root@truenas[~]# iostat ada3
       tty            ada3             cpu
 tin  tout  KB/t tps  MB/s  us ni sy in id
   0     4 17.28  13  0.21   0  0  3  1 95
 
root@truenas[~]# iostat ada2
       tty            ada2             cpu
 tin  tout  KB/t tps  MB/s  us ni sy in id
   0     4 17.20  13  0.21   0  0  3  1 95
 
root@truenas[~]# iostat ada1
       tty            ada1             cpu
 tin  tout  KB/t tps  MB/s  us ni sy in id
   0     4 315.99  78 24.12   0  0  3  1 95
 
root@truenas[~]# iostat ada0
       tty            ada0             cpu
 tin  tout  KB/t tps  MB/s  us ni sy in id
   0     4 327.69  75 24.01   0  0  3  1 95

 

[snaxilian]

150 IOPS gesamt beim Pool RaidStorage2 sind normal und was man erwarten würde bei HDDs. Du machst halt gerade read- und write auf den Pool, daher bekommst da 'nur' so wenig Durchsatz hin.
Viel anderes würdest mit einem NAS von der Stange auch nicht hinbekommen bei einem klassischen Raid 1.

fürs schnelle lesen/schreiben von Daten

Wie bereits schon einmal gesagt: Eine mirrored VDEV liefert beim schreiben die Geschwindigkeit einer einzelnen HDD. Willst du da mehr im Pool erreichen, musst du mehrere VDEVs in den Pool packen oder bei kleineren Datenmengen eine entsprechende SSD als Schreibcache verwenden oder eben einen reinen SSD Pool erstellen.

Nur um sicher zu gehen: Die verwendeten HDDs sind aber schon CMR/PMR Modelle und keine SMR HDDs, oder? SMRs haben in einem Raid/ZFS Verbund nix zu suchen.

(Bin ein wenig enttäuscht)

Wovon? Von deiner eigenen blauäugigen Wunschvorstellung, dass eine einzelne HDD langsamer ist als eine SSD und 2,5/10 GBit/s Netzwerk?^^ Sagt doch auch das Datenblatt: Im perfekten Idealfall unter Laborbedingungen schafft die WD Gold 8TB bis zu 225 MB/s.

 

[Clapinoson]

Du machst halt gerade read- und write auf den Pool, daher bekommst da 'nur' so wenig Durchsatz hin.

Aber wieso, ich habe bei meinen Testläufen immer nur in eine Richtung kopiert.

Aber gut, ich denke, dass ich mein "Problem" jetzt ungefähr verstanden habe, ich werde mir noch einen SSD Pool anlegen und die WD Gold dann als Datengrab verwenden.


ZFS SLOG / ZIL werde ich in Erwägung ziehen, ein schneller SSD Pool wird denke ich, fürs Erste auch keine schlechte Entscheidung sein.

Nur um sicher zu gehen: Die verwendeten HDDs sind aber schon CMR/PMR Modelle und keine SMR HDDs, oder?

Die Herstellerangaben von meiner Gold, ja ist eine CMR :-)

Typ    Festplatte
EAN    0718037872681
Hersteller-Nr.    WD102KRYZ
Serie    WD Gold
Bauform    3,5 Zoll
Kapazität    10 TB
Schnittstelle    1x SATA/600
Stromanschluss    15-Pin-Stromanschluss
Aufnahmetechnik    CMR (Conventional Magnetic Recording)
Datentransferrate    Lesen    262 MB/s
Drehzahl    7.200 U/min
Sektorgröße    4 KB mit Emulation (512e)
Cache    256 MB
Lautstärke    Betrieb    38 dB(A)
    Ruhe    34 dB(A)
Stromverbrauch    Betrieb    9,2 W
    Ruhe    8 W
MTBF    2.000.000 Stunden
Feature    24/7 Dauerbetrieb, RoHS konform | Native Command Queuing (NCQ)
Abmessungen    Breite: 101,6 mm x Höhe: 26,1 mm x Tiefe/Länge: 147 mm
Gewicht    738 Gramm

Vielen lieben Dank, für deine kompetente Beratung und akkurate Hilfestellung!


LG
Philipp

 

[fgordon]

Hmmm die ZFS Versionen haben auch ab und an etwas strange Performanceprobleme, die dann in irgendeiner Version meist gefixt werden Auf meinem MainServer compiliere ich deshalb ZFS immer selber.

Siehst ja hier auch in den Changelogs, Performance ist immer ein Thema - TrueNas ist ja FreeBSD mit Aufsatz. Sowas wie Du hatte ich auch schon - aktuell mit 2.1.5 aber noch nicht.

https://github.com/openzfs/zfs/releases/tag/zfs-2.1.5

bzw für alle Versionen (inkl FreeBSD) https://zfsonlinux.org/

 

[Clapinoson]

Hi, danke für den Hinweis. Ich werde es mir überlegen, ob das mit dem selber kompilieren eine Option für mich ist. Eigentlich habe ich mich für Truenas entschieden, weil ich eben selber weniger am System herumschrauben will^^