October 28, 20241 yr Hallo zusammen, gibt es hier im Forum FS allgemeine Empfehlungen? Würdet ihr stand heute noch auf XFS setzen oder schon eher richtig ZFS gehen? Ich verwende die Ugreen NAS DXP2800 2-Bay mit N100 CPU und 8 GB Ram mit zwei Festplatten Exos 16TB (XFS - encrypted + Parity) mit einer 1 GBit Ethernet Schnittstelle. Lesegeschwindigkeit passt, hier lasste ich die 1 Gbit Schnittstelle voll aus, aber beim Schreiben halbiert sich das ganze auf 50 Mbyte/s. Ich bin mir nun nicht sicher woran das liegt. An Unraid selber, weil er auf zwei Platten schreiben muss, an der Verschlüsselung (CPU Last ist bei 30%), am FS? Beobachtet ihr bei euren System das gleiche Verhalten? Grüße
October 28, 20241 yr Hi, das Unraid beim Schreiben auf das Array relativ langsam ist ist mit vorhandener Parity normal. Das leigt in daran, dass yeitglich die Paritaet mit geschrieben werden muss. Um dieses zu kompensieren gibt es den Cache, der in Unraid eben als Schreibcache dem Array vorgeschaltet wird. So werden die eingehenden Daten erst auf den schnelleren Schreibcache zwischen gespeichert, um dann je nach Einstellung und individuellen Wuenschen auf das Array kopiert zu werden.
October 28, 20241 yr Community Expert 45 minutes ago, iceball09 said: gibt es hier im Forum FS allgemeine Empfehlungen? Forum FS? 45 minutes ago, iceball09 said: Würdet ihr stand heute noch auf XFS setzen oder schon eher richtig ZFS gehen? Einzeldatenträger (auch Array): xfs Wenn man Datenträger in einem Pool verbinden will ( seit unraid 6.12.x) : zfs. 45 minutes ago, iceball09 said: Lesegeschwindigkeit passt, hier lasste ich die 1 Gbit Schnittstelle voll aus, aber beim Schreiben halbiert sich das ganze auf 50 Mbyte/s. Da muß ein Fehler vorliegen. Bei einem Array mit nur 2 Datenträgern (1D+1P) ist die Schreibgeschwindigkeit nativ so hoch, wie das, was die langsamste Festplatte/SSD leisten kann. Zusatzinfo: egal ob xfs, zfs, btrfs, oder irgendein anderes OS: Bei einem Array mit mehr als 2 Datenträgern (mit Parity) ist die Schreibgeschwindigkeit naturgemäß zwischen 33 und 50% dessen, was die Datenträger alleine, an der zu beschreibenden Stelle, leisten können. Deshalb puffert man Schreibzugriffe auch in einem Pool mit SSDs. 45 minutes ago, iceball09 said: Ich bin mir nun nicht sicher woran das liegt. Am Array, so wie es benutzt wird. Dadurch spart das Array ja auch Strom (bei einem Array mit mehr als 2 Datenträgern). Du kannst das mit "Reconstruct Write" umgehen. Dann wird schneller geschrieben, aber auch alle Datenträger laufen und Stromsparen ist nicht. 45 minutes ago, iceball09 said: An Unraid selber, weil er auf zwei Platten schreiben muss, an der Verschlüsselung (CPU Last ist bei 30%), am FS? Die Verschlüsselung macht eine heutige CPU (auch die N100) nebenher. Das bremst normalerweise nicht. Ich befürchte im Array sind irgendwie mehr als 2 Datenträger (angemeldet). 45 minutes ago, iceball09 said: Beobachtet ihr bei euren System das gleiche Verhalten? Im Array mit Parity & mehr als 2 Datenträgern (ohne Recontruct write): klar! Kannst ja mal Deine Diagnostics bieten. Vielleicht sehen wir dann mehr. Edited October 28, 20241 yr by DataCollector
October 28, 20241 yr Author Schonmal vielen Dank für die Rückmeldungen. Vollständigkeitshalber nochmal erwähnt: Ich habe eine Festplatte im Array (XFS - Verschlüsselt) und eine Festplatte als Parity und eine SSD (btrfs) als Cache. Ich spreche hier "nur" von der Schreibleistung direkt ins Array und nicht auf die SSD. Die Diagnosedaten habe ich mit angehängt dxp2800-diagnostics-20241028-1449.zip
October 28, 20241 yr 36 minutes ago, iceball09 said: Vollständigkeitshalber nochmal erwähnt: Ich habe eine Festplatte im Array (XFS - Verschlüsselt) und eine Festplatte als Parity und eine SSD (btrfs) als Cache. Ich spreche hier "nur" von der Schreibleistung direkt ins Array und nicht auf die SSD. dann stell mal in den disks settings um md_write_method von "auto" auf "reconstruct" 5 hours ago, iceball09 said: An Unraid selber, weil er auf zwei Platten schreiben muss, an der Verschlüsselung (CPU Last ist bei 30%), am FS? und auch wenn die gesehene Last bei der Verschlüsselung bei 30 % liegt ist das eine Bremse ... aber teste mal zuerst das oben genannte ... und bitte Tests mit einer großen (Image) Datei und nicht mit vielen Kleinen ...
October 28, 20241 yr Nachtrag, du nutzt auch noch ne USB disk in unassigned ? und testest nicht auf diese ? dann waren da noch ein paar Fehler, aber von vorgestern ... denke die sind behoben Zeile 1252: Oct 26 08:35:10 DXP2800 emhttpd: /mnt/disk1 mount error: Unsupported partition layout Zeile 1257: Oct 26 08:35:10 DXP2800 emhttpd: ERROR: not a valid btrfs filesystem: /dev/nvme0n1p1 Zeile 1262: Oct 26 08:35:10 DXP2800 emhttpd: /mnt/cache mount error: Unsupported or no file system Zeile 1427: Oct 26 08:38:16 DXP2800 root: wipefs: error: /dev/nvme0n1p1: probing initialization failed: No such file or directory wenn schon dabei, du hast im Netzwerk ... bond konfiguriert (einen Verbund) aber nur eine NIC aktiv ... würde ich mal umstellen, und wenn schon dabei ... dhcp ... Server mögen immer lieber fixe IP's. hat jetzt nichts mit der Schreibleistung am Hut ... aber wenn schonmal dabei ... dann nutzt du ein single drive cache ... das im btrfs mode ... wenn du hier etwas suchst ... nicht unbedingt empfohlen, single drive würde ich persönlich immer xfs nehmen, ist einfach rock solid ... sag Bescheid ob reconstruct was geändert hat am Schreibverhalten
October 28, 20241 yr Author 3 hours ago, alturismo said: dann stell mal in den disks settings um md_write_method von "auto" auf "reconstruct" und auch wenn die gesehene Last bei der Verschlüsselung bei 30 % liegt ist das eine Bremse ... aber teste mal zuerst das oben genannte ... und bitte Tests mit einer großen (Image) Datei und nicht mit vielen Kleinen ... Ich habe es mit einer 15Gb großen mkv Datei versucht. Die Umstellung hat leider nicht geholfen:
October 28, 20241 yr 9 minutes ago, iceball09 said: Ich habe es mit einer 15Gb großen mkv Datei versucht. Die Umstellung hat leider nicht geholfen: ok, das ist echt schwach ... mal lokal getestet (zum Ausschluss) cp /mnt/cache/abc/testfile /mnt/disk1/def/testfile nur um sicher zu sein ob es Netzwerk oder disk performance ist ...
October 28, 20241 yr Author Lesen kann ich über das Netzwerk mit 100Mb/s: Von HDD auf Cache (mit 15 GB mkv-Datei): Von Cache auf HDD (mit 15 GB mkv-Datei): - Ist schneller, wie übers Netzwerk. Würde hier aber hier etwas von 200 MB/s erwarten. Achso könnte ein nicht vollständige gesyncte Parität die Schreibleistung reduzieren? ich habe das bisher abgebrochen, da dies so lange braucht und ich das erst am Ende, wenn ich alle Daten auf dem Server hochgeladen habe, machen wollte. Edited October 28, 20241 yr by iceball09
October 28, 20241 yr Author Oder ist doch einfach nur die Daten Festplatte der Flashenhals, weil sie Schreiben und lesen gleichzeitig muss und dies nich perfomant kann:
October 28, 20241 yr Just now, iceball09 said: Oder ist doch einfach nur die Daten Festplatte der Flashenhals, weil sie Schreiben und lesen gleichzeitig muss und dies nich perfomant kann: unwahrscheinlich, das kommt von der Parität, aber deine disks sind CMR und sollten das ab können
October 28, 20241 yr You must finish the parity sync first, testing with invalid parity won't give realist results, and turbo write won't work.
October 28, 20241 yr Author Thank you for your hint. I also found a problem in my network (Router Fritzbox 6590 ax). I tested now with a switch and the resualts now much better: I also tested it without the Partiy Disk and the switch: I would say this looks now fine. Thank you all for your support Edited October 28, 20241 yr by iceball09
October 28, 20241 yr Community Expert 2 hours ago, iceball09 said: Achso könnte ein nicht vollständige gesyncte Parität die Schreibleistung reduzieren? ich habe das bisher abgebrochen, da dies so lange braucht und ich das erst am Ende, wenn ich alle Daten auf dem Server hochgeladen habe, machen wollte. Hast Du also nun die Parität aktiv oder nicht? Ich weiß nicht , wie sich unraid in dem Fall verhält, aber Du deutest mit den Screenshots ja an, daß dennoch die Parityplatte benutzt wird. Also kann es da bremsen. Ja. Nebenbei: Warum hast Du bei einem 2 Disk-System die Parity nicht direkt mit schreiben lassen? Nachträgliches Erstellen macht bei einem 2 Disk System (1D+1P) keinen wirklichen Sinn und schluckt nur extra Zeit.
October 29, 20241 yr Community Expert Bei nur zwei Disks im Array, wobei eine die "Parity" ist, handelt es sich auch um einen Sonderfall. In dem Szenario wird mit den beiden Disks ein RAID1 gebildet. Es ist also ein Mirror. Die "Parity" enthält also tatsächlich Daten. Die der "Daten"-Disk. Ab drei Platten ist das nicht mehr der Fall. Dann ist die Parity tatsächlich eine Disk rein mit Paritätsinhalt und keinen tatsächlichen Daten einer der beiden "Daten"-Disks. Edited October 29, 20241 yr by saber1
October 29, 20241 yr 10 hours ago, iceball09 said: Achso könnte ein nicht vollständige gesyncte Parität die Schreibleistung reduzieren? ich habe das bisher abgebrochen, da dies so lange braucht und ich das erst am Ende, wenn ich alle Daten auf dem Server hochgeladen habe, machen wollte. das hab ich eben erst gesehen ... ja klar reduziert das ... lass erstmal fertig laufen und teste dann ... ei ei ei ...
October 29, 20241 yr Author 10 hours ago, DataCollector said: Hast Du also nun die Parität aktiv oder nicht? Ich weiß nicht , wie sich unraid in dem Fall verhält, aber Du deutest mit den Screenshots ja an, daß dennoch die Parityplatte benutzt wird. Also kann es da bremsen. Ja. Nebenbei: Warum hast Du bei einem 2 Disk-System die Parity nicht direkt mit schreiben lassen? Nachträgliches Erstellen macht bei einem 2 Disk System (1D+1P) keinen wirklichen Sinn und schluckt nur extra Zeit. Es wird doch auf die Parity Disk und Data Disk zeitgleich geschrieben. Zumindestens interpretiere ich das hier so: P - Parity D - Data Summe des Arrays
October 29, 20241 yr Community Expert 2 hours ago, iceball09 said: Es wird doch auf die Parity Disk und Data Disk zeitgleich geschrieben. Zumindestens interpretiere ich das hier so: P - Parity D - Data Summe des Arrays Darauf will ich ja hinaus: Du hast das Paritybuilding Deiner Aussage nach mitten drin abgebrochen (warum auf immer, da die Parity eigentlich von Anfang an bei einem 2 Disk (1D+1P) Modell sinnvoll ist und nicht bremst). Somit sind viele der Sektoren der Paritydisk zum Teil falsch. Leider kann unraid aber nicht wissen, welche korrekt und welche falsch sind, da es eigentlich davon ausgehen muß, daß eine Parity vollständig korrekt ist. Da unraid aber jetzt (wie Deine Screenshots wunderbar zeigen) parity schreibt (weil Du die Paritydisk drin hast) kann unraid keinem dortigen Sektor vertrauen und muß nun auf Datendisk lesen und schreiben um dann die Parity korrekt zu schreiben. Da ist ein Überbleibsel der Funktion bei Array mit eben mehr als 1 Datendisk. Deinen krummen Sonderfall haben die eben nicht bedacht. Wenn es ganz schlimm läuft (und genau so liest sich das hier) bremst Du durch die Verwendung einer nicht korrekten Paritydisk alle Schreibenden Vorgänge aus. Mögliche Ansatzpunkte: a) Entweder entfernst du jetzt die Paritydisk (die zu einer Wiederherstellung sowieso nicht taugt, da ja vieles darauf falsch ist), befüllst erst einmal Deine Datendisk soweit es erforderlich ist, um die andere Disk dann als Parity hinterher wieder dazu zu nehmen und dann synchronisieren/aufbauen zu lassen. b) oder Du stoppst erst einmal das Befüllen der Datendisk, läßt die eingebaute Paritydisk sich erst einmal vollständig synchronisieren (Paritycheck) um dann erst danach weiter zu befüllen. c) oder (vermutlich nicht so gewünscht): Du entfernst die Parity komplett und arbeitest nur noch mit einem 1 Disk System (bzw nimmst die 2. Disk ebenfalls als Datendisk dazu) ohne Parity. Such Dir etwas aus, aber lass dann unraid erst einmal seine Arbeit machen, bevor Du ihm da rein grätschst. Und danach kann man ernsthaft nach Gründen für den Geschwindigkeitsverlust suchen (sofern der bei Deinem 2Disk (1D+1P) System dann überhaupt noch auftritt). Und ja, ungefär das wollte Dir wohl JorgeB oben auch schon mitteilen (vermute ich).
October 29, 20241 yr Author Solution Okay, das Problem waren bei mir nun die fehlende Synchronität der Paritydisk und mein Router/Netzwerk. Vielen Dank für euren Support Edited October 29, 20241 yr by iceball09
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.