Ich trau mich und baue meine NAS selbst.

[Quarzer]

Hm... spielt fast keine Rolle Ob nun 2 x PCI 4.0 oder 3.0 ist beides gleich selten bzw. 4.0 sogar häufiger.

 

[Banned]

Also Boards mit zwei PCIe 4.0 m.2 Slots gibt es doch einige:

https://geizhals.de/?cat=mbp4_1700&...c=at&hloc=de&hloc=pl&hloc=uk&hloc=eu&v=e&pg=1

Welche davon Bitfurcation über den PCIe 5.0 Slot können - falls du hier in Zukunft mit Adapterkarte noch mehr NVMe-SSDs im RAID betreiben möchtest, ist eine andere Frage, sofern das überhaupt für dich relevant wäre.

 

[Kasjo]

Schneller als ein Array in Unraid ist beides, das stimmt.

Und um nichts anderes geht es hier.

Block-Prüfsumme auf Dateisystemebene

Lässt sich unter Unraid nachrüsten. Gibt meiner Meinung nach n Plugin dafür. Ist aber nur ein Teil des Konzepts und auch nur wenig Sinnig nur einen teil davon umzusetzen.

Grundsätzlich bietet ZFS schon mehr, bin ich bei dir, nur werd ich jetzt nicht mitspielen und einzelne fizelchen rauszupicken und durchzukauen was ZFS kann und was nicht. Das ist nicht Zielführend.
ECC war und ist hier kein thema, ergo ist es offensichtlich ja auch wurscht was mit den daten im Ram passiert.

Und wenn ich meine Daten von a nach b schiebe und die dann durch bitflip im NAS beschädigt in den Pool kommt, kann ich natürlich hergehen und mit Prüssummen sicherstellen das im falle einer wiederherstellung die datei auch so defekt bleibt. Halte ich nur nicht für sinnig. Zumindest für n archiv.

Bei nem NAS das nur für spielerein und nicht wirklich relevante daten oder wichtige her hält weil ich noch zwei drei backups habe, ja dann kann ich mich auf Prüfsummen alleine verlassen. Dann langt aber auch n array mit parität.

 

[andy_m4]

Es reicht aber auch einfach einen Blick auf den Pool zu werfen.

Hab ich gemacht mit:
zpool iostat -v 1
und kann das von Dir beobachtete Schreibverhalten nicht nachvollziehen. Schreibzugriffe kommen eigentlich mit ein paar Ausnahmen dann vor, wenn es ein Prozess (wie z.B: Firefox, wenn er in seinem Cache rumrühert) tatsächlich auch was auf Disk schreibt.

Das ZFS auch von sich aus hier und da Schreibzugriffe initiiert will ich dabei gar nicht in Abrede stellen. Aber die von Dir suggerierte Menge sehe ich nicht.

 

[Banned]

ECC war und ist hier kein thema,

Naja, du hast ihn ja ins Gespräch gebracht.

ergo ist es offensichtlich ja auch wurscht was mit den daten im Ram passiert.

Wurscht nicht, aber alles ist eine Sache von Wahrscheinlichkeiten. Bitfehler im RAM sind bei einem Durchschnittsnutzer, der nicht etliche TB bis PB pro Jahr transferiert, m.E. ein recht überschaubares Risiko, zumal auch nicht jeder Bitfehler gleich zu einem merklichen Fehler führt. Ich persönlich nutze auch ECC-RAM im NAS; meine Endgeräte (Desktop und Laptops) haben hingegen keinen - eigentlich müsste ich hier auch konsequenterweise welchem verwenden - ist alles ne Sache der Risikoabwägung.
Dafür nutze ich wiederum RAIDZ2 gegen den statistisch irgendwann kommenden unrecoverable read error; damit er nicht beim Rebuild/Resilvering auftritt. So fährt halt jeder irgendwie seine Strategie. Bei mir persönlich hat es die höchste Priorität, dass die Daten, wenn sie einmal auf dem NAS sind, so bleiben.

Dann gibt es auch den noch unwahrscheinlicheren Fall von Multi-Bit-Errors. Hier braucht man dann ein professionelles Mainboard, um da überhaupt den Log einsehen zu können. (Habe ich, aber sicher nicht alle, die ECC-RAM nutzen.)

Du siehst, Kompromisse kann man viele machen, aber letztendlich ist ein Dateisystem wie ZFS ohne ECC-RAM immer noch besser als ein anderes (auch mit ECC-RAM).

Und wenn ich meine Daten von a nach b schiebe und die dann durch bitflip im NAS beschädigt in den Pool kommt, kann ich natürlich hergehen und mit Prüssummen sicherstellen das im falle einer wiederherstellung die datei auch so defekt bleibt. Halte ich nur nicht für sinnig. Zumindest für n archiv.

Aber das ist doch gerade der Sinn eines Archivs - dass es so bleibt, wie es einmal ist.

 

[Kasjo]

Aber das ist doch gerade der Sinn eines Archivs - dass es so bleibt, wie es einmal ist.

Ja aber nicht wenn sie ohne ecc fehlerhaft im pool landen. Das war mein gedanke bei der aussagge. Schon klar das es so bleiben soll aber halt korrekt. ZFS macht aber viel über ram und wenn halt da n fehler auftrifft werden die daten fehlerhaft in den pool geschieben.

Ergänzung (21. Februar 2025)

Du siehst, Kompromisse kann man viele machen, aber letztendlich ist ein Dateisystem wie ZFS ohne ECC-RAM immer noch besser als ein anderes (auch mit ECC-RAM).

Auch richtig, hab ja nichts gegen gesagt. Array kam zur sprache kam evtl. flexibel erweitern zu können usw. das kann zfs halt nicht. Nur mit weiteren Pools.
Und auch wenn man eben Spindown von HDDs nutzen möchte usw. ZFS ziehe ich dem klar vor.

Ergänzung (21. Februar 2025)

Hab ich gemacht mit:
zpool iostat -v 1
und kann das von Dir beobachtete Schreibverhalten nicht nachvollziehen. Schreibzugriffe kommen eigentlich mit ein paar Ausnahmen dann vor, wenn es ein Prozess (wie z.B: Firefox, wenn er in seinem Cache rumrühert) tatsächlich auch was auf Disk schreibt.

Das ZFS auch von sich aus hier und da Schreibzugriffe initiiert will ich dabei gar nicht in Abrede stellen. Aber die von Dir suggerierte Menge sehe ich nicht.

Ich habs mal weiter beobachtet.
Unter Unraid hab ich zugriffe alle paar sekunden von mehreren KB. Laut unraid interface sinds schreibzugrifft, laut IoStat nur IOs, also keine aktiven schreibvorgägne. So wies aussieht liegts wohl amd ZFS Master Plugin in Unraid was dafür verantwortlich ist.

Wurde anscheinen fehlinterpretiert von mir. Im Webinterface steht halt dran schreiben ^^, aber dann sinds nur Ios, welche durchs ZFS plugin verursacht werden. Mein Fehler.

 

[Quarzer]

Soooo... habe nochmal ein wenig rumgesucht. Ist das so okay? Oder sollte ich etwas austauschen? Wie gesagt wäre geringer Stromhunger wünschenswert.

https://geizhals.de/wishlists/4331457

 

[andy_m4]

Array kam zur sprache kam evtl. flexibel erweitern zu können usw. das kann zfs halt nicht.

Du kannst zu einem Pool "live" weitere "Platten" hinzufügen mit
zpool attach ...

Aus der Manpage von zpool-attach(8):

If the existing device is a RAID-Z device (e.g. specified as "raidz2-0"), the new device will become part of that RAID-Z group. A "raidz expansion" will be initiated, and once the expansion completes, the new device will contribute additional space to the RAID-Z group. The expansion entails reading all allocated space from existing disks in the RAID-Z group, and rewriting it to the new disks in the RAID-Z group (including the newly added device).

Und auch wenn man eben Spindown von HDDs nutzen möchte

Hab immer noch nicht verstanden, wo das Problem liegen soll.

 

[Quarzer]

Oder ich baue doch mit SSD und installiere TrueNas auf ne NVME.

Was meint ihr. Sieht das gut aus?

https://geizhals.de/wishlists/4332144

 

[Banned]

Soooo... habe nochmal ein wenig rumgesucht. Ist das so okay? Oder sollte ich etwas austauschen?

Ich würde eher dieses Netzteil im ATX 3.0 Standard nehmen:
https://geizhals.de/be-quiet-pure-p....html?hloc=at&hloc=de&hloc=pl&hloc=uk&hloc=eu

Neuere Netzteile sind im Niedriglastbereich effizienter. Ansonsten finde ich das so okay.

Zur zweiten Konfiguration: Die SFX-Netzteile sind nicht besonders effizient, hier sollte man dann eher ne PicoPSU nehmen. Warum so ein teures Mainboard?

PS: Mal ganz generell: Allen Auto-OC-Quatsch (Multicore Enhancement o.Ä.) auf den Mainboards deaktivieren, ebenso wie alle Ports, die nicht benötigt werden. Außerdem die TDP der CPU begrenzen.

 

[Quarzer]

Thema ATX wäre jetzt das hier:
https://geizhals.de/be-quiet-pure-power-12-m-550w-atx-3-0-bn341-a2884050.html

Welches Motherboard würdest du empfehlen? Muss nicht so teuer sein.

Wie installiere ich TrueNas bei der ersten Config am besten? Ich brauch da wohl noch ne 3. Platte für TrueNas oder?

 

[redjack1000]

Beachte den Link in #42.

Cu
redjack

 

[Banned]

noch ne 3. Platte für TrueNas oder?

TrueNAS muss auf einem separaten Laufwerk installiert werden und da kann auch nichts anderes mehr draufgepackt werden. Also eine kleine, hochwertige SSD nehmen (also kein QLC und kein exotischer Controller).

 

[Quarzer]

@Banned Wäre die ok? Irgendwie gibt's kaum was besseres, gefühlt.

https://amzn.eu/d/i1q43XN

Ergänzung (21. Februar 2025)

Nen CPU Kühler brauch ich nicht, right?

 

[Banned]

Äh doch, du brauchst natürlich nen CPU-Kühler. Guck mal in meinen ersten Beitrag hier im Thread, da habe ich Konfigurationen verlinkt, da ist auch einer dabei.

Bei der SSD steht bei Geizhals nichts von TLC-NAND: https://geizhals.de/western-digital-wd-blue-sa510-ssd-500gb-wds500g3b0a-a2736520.html

Ich würde eine hiervon nehmen:
https://geizhals.de/samsung-ssd-870....html?hloc=at&hloc=de&hloc=pl&hloc=uk&hloc=eu

https://geizhals.de/samsung-ssd-870....html?hloc=at&hloc=de&hloc=pl&hloc=uk&hloc=eu

Bist du eigentlich sicher, dass dir 4TB reichen (also auch für die Zukunft)? Mit SATA könntest du halt leichter erweitern.

 

[Quarzer]

Ja, die 870er macht deutlich mehr Sinn. Danke. Plan ist mit 4TB zu starten. Damit sollte ich ein paar Jahre hinkommen (5 bestimmt). Zur Not tausche ich dann gegen 8tb SSDs aus, die dann hoffentlich weniger kosten.

Passt der CPU Kühler?

https://amzn.eu/d/dm31luJ

 

[redjack1000]

Passt der CPU Kühler?

Wenn ein Kühler, mit einer Höhe von 155mm in das Gehäuse passt, ja.

CU
redjack

 

[Quarzer]

Ahhh jo. Ne passen nur 75mm laut Gehäuseangabe.

 

[redjack1000]

Ja dann, weitersuchen.

Cu
redjack

 

[alturismo]

vielleicht auch mal zum Thema SSD in einem Unraid Array

ja, das ist nicht empfohlen aufgrund der TRIM Thematik

Hintergrund, wenn getrimmt wird würde bei Nutzung einer Parity diese immer wieder neu erstellt werden müssen da diese ja nicht file based läuft sondern simpel ausgedrückt, block based, das nur dazu.

aber ... es gibt ja mittlerweile einige Array SSD user und die merken mal zumindest nichts bei normaler NAS Nutzung, was auch Sinn ergibt im Datengrab ... die Parity wird sicherlich etwas darunter leiden mit der Zeit, aber die Erfahrungen sich durchweg positiv.

wenn die Array SSD's mit statischen Daten befüllt werden und da nichts groß gelöscht, neu beschrieben wird ... sondern normal mit neuen Daten befüllt werden ... wird TRIM auch keinen großen Unterschied machen.

Daher kann man da mittlerweile aus Erfahrung sagen

SSD im Array als Datengrab, ok
SSD im Array und "Wechseldaten", auf Sicht sicherlich nicht die beste Wahl

unter Wechseldaten verstehe ich jetzt aber permanentes Wechseln, appdata's, Docker Images, transcoding caches, Bearbeitungslaufwerke, usw usw ... dafür ist ein separater pool dann sicherlich die bessere Wahl.

was dann wenn multi device genutzt werden soll, btrfs oder zfs wäre

btrfs pool später zu erweitern, sollte gehen, zfs meine ich auch, da je nach zfs Stand was da angeboten wird.

wenn openzfs > 2.3 eingesetzt wird kann da auch zu einem bestehenden pool ein single device ergänzt werden wenn ich das richtig nachgelesen habe, das wissen jedoch andere sicher besser

da ich weder btrfs noch zfs nutze (beides für mich im privaten Umfeld overhyped und kein Mehrnutzen) setze ich nach wie vor auf single device xfs (stabil) und Backup Strategie, seit Jahren ohne issues, auch in den pools.

btrfs war mir persönlich zu anfällig.
zfs hatte ich getestet, hatte für mich aber keinen Mehrwert.

Wenn man mir einer Disk (SSD) startet, dann halt simpel als single drive pool, welches FS auch immer ... wenn ich Redundanz möchte, dann braucht es halt min. 2 disks, entweder in einem Array oder in einem Pool ...