Test QNAP TS-h686 im Test: Das Intel-Xeon-ECC-PCIe-2,5-GbE-ZFS-M.2-NAS

[luckysh0t]

Warum nicht NFS?

Oder iSCSI - wenn es um ausgelagerte Spiele und co geht, klappt das auch ganz gut.

 

[mgutt]

Warum nicht NFS?

NFS ist schneller, weil NFS von Haus aus Multi-Threaded ist und RSS unterstützt (glaube ich jedenfalls, da es keine NFS Dokumentation zu RSS Einstellungen gibt). Samba ist Single-Threaded und unterstützt nur optional RSS. Nutzt man ausschließlich Windows, dann unterstützt SMB von Haus aus RSS und sogar RDMA (die nennen das SMB Direct). Zu sagen, dass NFS grundsätzlich schneller ist, ist also etwas unfair, da man ja gar nicht SMB, sondern Samba nutzt.

Und NFS ist ja wiederum in Windows nicht standardmäßig vorhanden:
https://graspingtech.com/mount-nfs-share-windows-10/

Und ob NFS in Windows alle Features unterstützt?! Mich würde es nicht wundern, wenn Microsoft zB RSS deaktiviert, nur um SMB besser aussehen zu lassen.

Und wir beziehen uns ja eigentlich auf den Computerbase Test. Die werden denke ich kaum so viele Dinge einstellen und installieren, nur um zu zeigen was theoretisch möglich ist. Die packen das Teil aus, stecken die Platten rein, erstellen eine Netzwerk-Freigabe und fertig. Wobei ich es natürlich begrüßen würde, wenn sie auch FTP und NFS testen würden.

Ergänzung (11. Februar 2021)

Naja, das sollte aus dem Blockschaltbild eigentlich hervorgehen

Dem was? ^^ Seit wann gibt es denn sowas von QNAP oder Syno.

 

[Nagilum99]

Wisst ihr zufällig, wie die Lanes aufgeteilt sind? Laut Intel hat der Xeon 32 Lanes, von denen gehen 16 an die 2 x8 Slots, weitere 8 an die M2. Es bleiben damit noch 8 übrig. Sind die 2,5Gb Netzwerkchips dann mit jeweils 2 Lanes angebunden (was deren Übertragungsrate drosseln würde), oder ist da irgendwo noch ein PCIe-Switch verbaut, der hier etwas Lastausgleich machen kann?

Was für PCIe soll da wohl verbaut sein, dass 2 Lanes einen 2,5G Chip ausbremsen? PCIe 1?

Ergänzung (11. Februar 2021)

NFS ist schneller, weil NFS von Haus aus Multi-Threaded

NFS hat erst vor "kurzem" mit pNFS eine tatsächliche Beschleunigung erhalten. Vorher war iSCSI schnell die bessere wahl, weil es multipathing unterstützt. Wenn ich kann (budget und so) würde ich aber wieder auf FC setzen.

 

[mgutt]

Hier stand Schwachsinn im Quadrat

 

[DFFVB]

Hab mich schon gewundert ;-)

@All: Wenn hier fröhlich über NFS vs SMB vs iSCSI vs XYZ (FTP, SFTP, webdav) diskutiert wird, hat einer ne schöne Übersicht, wie sich das performancemäßig im Heimnetz verhält? Was ist am schnellsten? Verschieben von Back-Ups, als auch viele kleine Dateien?

 

[Skysnake]

Wenn du auf die kleinen Dateien nicht direkt zugreifen musst, dann am ehesten vorher packen. Zumindest unter Linux kann man sich da nette pipes bauen wo das on the Flyer geht.

Wenn die CPU schnell genug ist, dann kostet das auch keine transferzeit. 128C Epyc packt dir nen komplettes rootfs von einigen GB mit unzähligen files in Sekunden, wenn die Daten im Ram liegen.

Kommt also nur noch drauf an wie schnell du die Daten vom Filesystem gelesen bekommst und ob das Netz bzw der storage sequenziell das schnell genug wegschreiben kann oder nicht.

 

[KurzGedacht]

Die 1 GB pro 1 TB beziehen sich eigentlich auf die Nutzung von Dedup...Nur wird das gerne Unterschlagen.Ab 4 GB kann man mit ZFS flüssig arbeiten - wie du ja selbst angemerkt hast ^^.

Jo Dedup zieht ordentlich RAM.
Wobei nicht mal dabei der RAM zwingend notwendig ist. Es wird halt bloß extrem langsam sobald die Dedup-Tabelle auf den Storage ausgelagert werden muss.

Ich würde von Dedup generell abraten solange der voraussichtliche Faktor unter ~3 liegt. Lohnt sich vorher nicht so richtig.
Wenn viel Schreibperformance (IOPS) benötigt wird, würde ich Dedup generell immer ausschalten.

 

[DFFVB]

@Skysnake - Stichwort Heimnetz nicht übersehen ;-)

 

[Skysnake]

Hm... hast recht. Wird dann wahrscheinlich auf SSD im lokalen Rechnerbund 1G+HDD im Nas raus laufen. Sprich in dem Fall limitiert sehr wahrscheinlich das Netz.

Bei 10G tendenziell eher das NAS/HDD.

Mehr wird man ja eher nicht haben. 40G ist ECHT teuer. Vor allem gibt es das nur als (Up)Link an 10G Switchen und da ist man dann schnell bei 4k+ für den Switch. Das macht dann keinen Spaß mehr 150W max Power bei dem, den ich gerade im Blick habe mit 48×SFP+ &6×QSFP+. Wenn man aus den 6xQSFP+ QSFP28, also 100G macht, ist man sogar bei 200W...

Klar das ist nur unter voller Last, aber wenn man bedenkt das nen 1G Switch mit paar 10G Ports keine 30W zieht, dann ist das schon heftig.vor allem das läuft ja 24x7x365....

 

[mgutt]

Wenn du auf die kleinen Dateien nicht direkt zugreifen musst, dann am ehesten vorher packen. Zumindest unter Linux kann man sich da nette pipes bauen wo das on the Flyer geht.

Ja sowas hätte ich gerne für Windows <> Linux:

tar -c /path | ssh target "cat > /file.tar"

Also lokal tar ausführen, aber das Ergebnis direkt auf dem Ziel erstellen.

Das es tar und ssh ja mittlerweile auch für W10 Kommandozeile gibt, muss das doch auch irgendwie gehen oder ^^

 

[Skysnake]

Ja sollte eigentlich inzwischen gehen

 

[Oberst08]

Was für PCIe soll da wohl verbaut sein, dass 2 Lanes einen 2,5G Chip ausbremsen?

Hast recht, ich hatte mich bei den Übertragungsraten verschaut. Die 2 Lanes reichen auf jeden Fall.

 

[thuering]

Ist das eine Frage oder fehlt da die Hälfte ?

Das war eine Aussage. ZFS ist das einzig ernstzunehmende Fileserver-Dateisystem. Ich Scheiss auf Btrfs und den ganzen anderen Kack!

 

[Nagilum99]

Das war eine Aussage. ZFS ist das einzig ernstzunehmende Fileserver-Dateisystem. Ich Scheiss auf Btrfs und den ganzen anderen Kack!

Und wohl auch auf brauchbare Beiträge, bei dem ersten zumindest dürften einige gerätselt haben, was du uns mitteilen willst.

 

[mgutt]

@Nagilum99 Don't feed

 

[Wilhelm14]

Und wer saubere Backups macht, also 2 Kopien, der muss die Hashsummen nicht mal abspeichern, sondern kann dann im Problemfall einfach die Datei wiederherstellen, die am häufigsten vorkommt.

Wie machst du das praktisch? Ich habe z.B. einen Hashcheck im Kontextmenü oder vergleiche mit dem Total Commander "nach Inhalt". Aber ohne Abspeichern der Summen? Woher weiß ich, welches die richtige Summe, bzw. intakte Datei ist? Da ich das händisch mache, mache ich das nur bei den wenigsten Daten. Ich hätte am liebsten ein NAS, welcher auf ein Backup-Ziel synchronisiert, dabei vergleicht und bei Unterschieden erkennt, welches die richtige ist und die defekte Datei ersetzt. Am liebsten auf USB (NTFS) als Ziel. Ich weiß gar nicht, ob ZFS/BTRFS auf dem NAS da helfen kann und ich nicht in die falsche Richtung denke. Dann frage ich mich aber, warum das Marketing mit Buzzwords ZFS/BTRFS/ECC um sich wirft, wenn im Grunde ECC der HDD oder die Backup-Software das schon schafft. 🙂

Wenn es dich interessiert such mal nach folgenden Büchern

1. FreeBSD Mastery: ZFS
2. FreeBSD Mastery: Advanced ZFS

Wie gesagt, mich interessiert als Endnutzer gar nicht der ganze Hintergrund, sondern, ob mein NAS die Daten vor Defekt schützen, Defekt erkennen und beheben kann.

 

[mgutt]

Aber ohne Abspeichern der Summen? Woher weiß ich, welches die richtige Summe, bzw. intakte Datei ist?

Bei 2 Backups gilt das Prinzip der Häufigkeit, weil du die Datei dann ja 3x hast.

Ich hätte am liebsten ein NAS, welcher auf ein Backup-Ziel synchronisiert, dabei vergleicht und bei Unterschieden erkennt, welches die richtige ist und die defekte Datei ersetzt.

Das müsste man sich denke ich programmieren. Ich kenne jedenfalls keine Backup-Software, die am Ziel zusätzlich den Hash abspeichert, um dann in der Lage zu sein die richtige Datei automatisch zu erkennen. Ich kenne nicht mal eine, die einen über Änderungen dieser Art informiert.

Was aber in der Praxis gehen könnte ist zB rsync mit backup-dir und checksum. Beispiel:

rsync -ab --delete --checksum --backup-dir="/changes/$(date +%F)" /src/ /dst

Hierbei ist nun /dst immer ein 1:1 Abbild von /src. Alle Änderungen landen in "/changes". Ändert sich nun eine Datei durch Bitrot, wird rsync sie in /changes ablegen. Natürlich gilt das auch, wenn Dateien bewusst überschrieben oder gelöscht wurden.

Ein Script könnte nun das jeweils aktuellste "/changes" mit "/src" abgleichen. Fehlen die Dateien in "/src", gehen wir von einem Löschen aus und ignorieren das. Ist die Datei aber in "/src" enthalten, hat sie sich geändert. Wir gleichen nun die mtime ab. Hat sie sich geändert, hat der Nutzer sie überschrieben. Hat sie sich nicht geändert, müssen wir von einem Bitrot ausgehen. Die Liste mit den Dateien lässt man sich dann zB per E-Mail zusenden.

Natürlich nimmt man nicht bei jedem Backup "checksum". Es reicht ja, wenn man das 1x pro Woche macht, weil man bei einem täglichen Backup bereits 7 Kopien des Originals zur Hand hat.

Bei Unraid oder Synology würde ich dafür das Script mit einem Fehler enden lassen und eine Benachrichtigung auslösen, deren Inhalt die Ausgabe vom Script ist (welches die Bitrot-Verdächtigen per echo ausgegeben hat).

Will man das ganze platzsparend umsetzen, zB mit --link-dest, dann müsste ich noch mal überlegen. Aber das sollte denke ich auch gehen, in dem man rsync verbose arbeiten lässt und dann die Dateien abgleicht, die rsync neu verarbeitet hat.

Lange Rede kurzer Sinn. Wenn dann denke ich nur mit einem Script.

warum das Marketing mit Buzzwords ZFS/BTRFS/ECC um sich wirft, wenn im Grunde ECC der HDD oder die Backup-Software das schon schafft.

ZFS/BTRFS bieten durch CoW Vorteile und durch Snapshots, die andere Dateisysteme nicht haben. Außerdem kann der ECC der HDD ja durchaus versagen. Das ist zwar selten, aber trotzdem möglich. Es könnte ja zB der komplette Sektor inkl. dem ECC hinüber sein. Genau für diesen seltenen Fall kann dann die "Selbstheilung" des Dateisystems greifen. Diese funktioniert allerdings nur in einem RAID und nicht bei Einzellaufwerken (viele wissen das nicht, deshalb sage ich das noch mal). Die Frage ist ob man eine permanente Last auf CPU und HDD und dafür eine automatische Selbstheilung möchte (ZFS/BTRFS als RAID) oder lieber ein performantes Dateisystem mit geringer Last und sich dann selbst um die Checks kümmert.

 

[Skysnake]

Lass doch das '--delete' einfach weg beim rsync dann haste auch kein Problem mit unabsichtlich gelöschten Dateien. Alsonao lange du nicht nur den Inhalt löschst...

 

[mgutt]

Lass doch das '--delete' einfach weg beim rsync

Ja. Aber dann enthält "/dst" dauerhaft auch die gelöschten Dateien. Unter einem Backup verstehe ich was anderes.

 

[Skysnake]

Und das haste innerhalb der Snapshots ja auch.