Test Synology DS223 im Test: Das NAS für den Standard-Nutzer

[MidwayCV41]

@conf_t schade, das wusste ich nicht. Naja, die eierlegende Wollmilchsau wird man wohl nach den jährlichen Eskapaden seitens Synology nicht erwarten können. Aber ich gebe die Hoffnung nicht auf:

• M.2 Slots mit Volume-Unterstützung auch mit nicht-syno-Riegeln

Funktioniert doch mit einem Trick. Habe eine M2 SSD in meinmer DS 920+ als Volumen laufen.

 

[Wechsler]

Wage sehr zu bezweifeln, dass ne einfache PCIe zu SATA - Adapterkarte über 9.69W (laut Geizhals) braucht.

Ein JMB582 (PCIe Gen3x1) kommt in einem QFN48 6x6 Package und wird mit 1,25 V Kernspannung ohne Kühlkörper betrieben. Wenn man irgendwo 10 W verheizen will, dann mit Checksum-Offload in einem ASIC, der in einem uralten Prozeß gefertigt wurde.

 

[LarionovC]

Die DS220+ verbraucht im Ruhezustand nach meinen Messungen mit Brennenstuhl PM 231 E: 3,8 WATT. Dieser Wert entspricht praktisch der Messung durch PCWelt und ct über jeweils 3,7 Watt (wobei beide Redaktionen wahrscheinlich deutlich höherwertige Messinstrumente benutzen). CB will für die DS220+ hingegen nur 1,8 Watt gemessen haben und für die neue DS223 mit 2x 4 TB IronWolf lediglich 2,4 Watt - beides ist nicht glaubhaft; zumal Synology für die DS223 4,08 Watt angibt.

 

[conf_t]

Da bin ich voll bei dir, dass bei CB da was mit den Messungen der x20+er Modellen fishy ist und damit hier bei den Lesern falsche Erwartungshaltungen schürt.

 

[ssh]

@LarionovC

vermutlich weil CB solche Ergebnisse würfelt. Manchmal weichen sie auch nach oben ab, gerade wenn man in die Liste mit den CPU Verbräuchen schaut.

 

[LarionovC]

"fishy"

gefällt mir

 

[zivilist]

2 Anmerkungen:

• Warum wieder ein 60 Watt Netzteil bei einer NAS welches vermutlich nie an 40 Watt verbrauchen wird?
• warum wird ständig ECC angemerkt? Ich habe seit Jahren Synology NAS (seit ca. 2015 oder 2016) und nie mit Abstürzen zu tun. Genau das Gleiche am PC, welcher wenn dieser abstürzte nie der RAM Schuld war.

 

[conf_t]

nie mit Abstürzen

Darum geht es bei ECC nicht.
Es geht am Ende darum das Umkippen von Bits zu verhindern. Also das unbemerkte Verändern von Daten während z.B. eines Kopiervorgangs aufs NAS. Ich betreibe seit 15 Jahreen Datengräber, seit 8 Jahren mit ECC, und ich habe vor allem davor in Dateien Bitfehler bekommen (in MP3s zu hören, in Videos zu sehen). Wodurch die genau entstanden sind kann ich im Nachhinein nicht sagen. Und wenn die Kette der Geräte mit ECC nicht konsistent ist, ist der Effekt bei einem Gerät auch gering. Aber seit DDR5 ist ein rudimentäres ECC Standard.

 

[zivilist]

@conf_t :
Das ist mir schon klar. Ich habe seit ca. 2001 oder 2002 keine Kopierfehler gehabt. Und ja ich kenne das Problem mit den Fehlern in mp3s.

 

[conf_t]

Offensichtlich nicht, sonst hättest du nicht versucht einen Zusammenhang zu Abstürzen herzustellen, um die es dabei eher weniger geht. Und irgendwie steht die Aussage, du kennst das mit Kopierfehlern aber hättest nie welche gehabt auch im Widerspruch. Ich habe hier 20 Jahre alte MP3s bei denen es irgendwie irgendwann zum Bit-Flip kam. Ein gutes Dateisystem (ZFS/BTRS) kann so was beim Ablegen minimieren und benötigt ECC im Idealfall. Und beim halten der Dateien im RAM mit anschließenden Schreiben, oder Scrubbing ist das auch in dieser Hinsicht von Vorteil.

Es ist nur ein kleiner Baustein zur Vermeidung von Bitflips, aber irgendwann, ist dann mal alles „in trockenen Tüchern“.

 

[Wilhelm14]

Gibt es dazu eigentlich irgendwo einen aufklärenden Bericht oder Artikel, z.B. bei heise/c't?
Ich bin seit Jahren am Rätseln, wie ich data/bit rot/flip erkennen und verhindern kann.
Ich kenne auch MP3, wo hörbare Fehler enthalten sind, die ich - sofern meine Erinnerung mich nicht täuscht - früher nicht da waren.
Es werden immer Begriffe genannt, ECC, ZFS, BTRFS, aber nie, ob im fertig eingerichtetem Betrieb nun alles safe ist. Ich meine bei Synologys Einführung von BTRFS war das nur rudimentär und die Funktion, Bit-Flip zu verhindern, wurde gar nicht genutzt. Mir wäre sogar etwas wie ein Log lieb. ...possible bit flip detected - repaired...

 

[conf_t]

Bit rot, also das kippen eines Bits auf dem Datenträger ohne dass die Datei verarbeitet wird kann man mMn mit gelegentlichem Scrubbing verhindern (abgleichen der Paritäten). Dazu wird die Datei aber im RAM verarbeitet und da wären wir wieder beim ECC. Auch entsprechende Dateisysteme wie ZFS und BTRFS sollen das verhindern können (NTFS oder ext4 gehören nicht dazu).

Hier was zu ECC
https://www.aboutnas.de/nas-arbeitsspeicher-ecc-ram-funktion-kaufberatung/

 

[Wilhelm14]

Ja, so in der Theorie verstehe ich das irgendwie. Aber in der Praxis müsste der NAS-Hersteller in seiner Bedienoberfläche da einen Menüpunkt oder eine Anzeige für haben. Bit Rot aktiv, nicht aktiv, hat verhindert, hat nicht verhindern können,... Sonst wirbt Synology einfach mit dem Wort BTRFS, nutzt das in Geräten ohne ECC RAM und die Möglichkeit mit BTRFS Daten zu "heilen" ist gar nicht aktiv.
https://www.computerbase.de/2021-04...perrt-btrfs-laufwerke-ohne-vorwarnung-wieder/

Edit: Ich als Endkunde/Laie denke: ECC? Check! BTRFS? Check!. Und in echt ist da gar keine automatische Heilung am Werk.

 

[conf_t]

Bit Rot aktiv, nicht aktiv, hat verhindert, hat nicht verhindern können,... Sonst wirbt Synology einfach mit dem Wort BTRFS, nutzt das in Geräten ohne ECC RAM und die Möglichkeit mit BTRFS Daten zu "heilen" ist gar nicht aktiv.

bezüglich ECC „merkt“ das OS davon nichts, das findet auf so tiefer Ebene statt, dass das OS davon bei normalen ECC nichts merkt.
Beim einfachen ECC wird ja nur festgestellt, ob die Information noch der Checksumme stimmt und dann entweder weiterverarbeitet oder nicht. Das ist eher so“ hmm, hier stimmt was nicht, noch mal von vorne“. Nicht „in Datei xyz ist Bit 2858 umgekippt“. Mit RegECC ist da schon mehr zu machen, aber auch das ist noch sehr transparent.

Und ja, Synology nutzt nicht alle verfügbaren Features von Btrfs, aber bis vor paar Jahren hatten sie nicht mal das.

Das kann man mit Paketverlusten vergleichen. Hier wird vom Ethernetframe auch eine CRC gebildet beim abschicken. Beim nächsten aktiven Gerät (Switch, Router,Modem) wird sie überprüft. Stimmt sie, alles gut, stimmt sie nicht wird der Frame stillschweigend verworfen und erst der Empfänger kann es merken, wenn in der Paketfolge was fehlt und es erneut anfordern. Das verwerfende Gerät ist gar nicht in der Lage die fehlende Information wiederherzustellen, soll und braucht er auch nicht .

Bei „guten“ Boards hat man zu ECC Counter im BIOS, bei einfachen nicht. Tun tun sie beide. Gerade z.B. bei Ryzen Board schwer zu testen ob ECC wirklich an ist oder nicht, weil die Consumerboards das zwar an sich unterstützen und viele CPUs, aber kein Interface haben das anzuzeigen.

 

[Gamienator]

@Gamienator Openmediavault, hatte ich auch schon mal auf einen 3er Pi probiert, was mich da ein bisschen gestört hatte, das ich max 11.2 MB/s up/download und nach nicht mal ein Monat kein update mehr möglich war

Genau deshalb entschied ich mich auch für ein klassisches Debian. Den WebUI brauchte ich nicht 😄

 

[mischaef]

@conf_t
Kann das Phänomen auch dafür verantwortlich sein, dass bei mir teilweise viele MP3 mit 0 Byte übertragen wurden? Ist recht blöd, wenn das erst später auffällt...

 

[conf_t]

@mischaef nein

 

[MountWalker]

Wobei ECC-RAM auch nur die Bit-Flips im RAM erkennt. Flipt ein Bit auf dem Weg irgendwo zwischen CPU und RAM, hast du einen Speicherfehler, der nicht im Speicher entstanden ist. Auf Gaming-Rechnern kommt das durchaus vor. Such mal beispielsweise webweit danach, was einige Overclocker zu Prime95 schreiben. Da kommen gelegentlich Schoten wie "Prime95 überfordert halt alles, das kann gar nicht rund um die Uhre stabil sein, wenn der Speicherfehler erst nach einer Stunde Prime kommt ist mir das stabil genug".

Und das ist genau der Grund, warum ECC-RAM bei Desktop-Rechnern in den Augen vieler "nicht gebraucht" wird - Speicherflips sind auf, ja schlecht gebauten/konfigurierten, aber doch vielen Heimcomputern unabhängig von der Frage nach ECC-RAM Alltag. Diese Bit-Flips verschwinden dann auch mit ECC-RAM nicht, weil sie ja nicht im RAM-Chip während des Gespeichertseins passieren, sondern bei der Verarbeitung.

P.S.
Atomare Operationen sorgen wenigstens dafür, dass ein Defragmentieren nicht mehr Dateien durch einen instabil laufenden Prozessor oder Controller shreddern kann - sofern das Dateisystem sowas erlaubt.

 

[TomH22]

Wobei ECC-RAM auch nur die Bit-Flips im RAM erkennt. Flipt ein Bit auf dem Weg irgendwo zwischen CPU und RAM, hast du einen Speicherfehler, der nicht im Speicher entstanden ist.

Das stimmt so nicht, die ECC Prüfung findet erst im Speichercontroller des Prozessors statt. Sie sichert damit nicht nur den Speicherinhalt, sondern auch die Übertragung mit ab.

Auf Gaming-Rechnern kommt das durchaus vor.

Da Gaming Rechner in der Regel mit übertaktetem RAM und ggf. auch übertaktetem Speichercontroller betrieben werden (auch einfach XMP einschalten ist schon Übertaktung), sind Fehler deutlich wahrscheinlicher. Die entstehen auch in der Tat „auf dem Weg“ und nicht im Speicher selbst. Denn übertaktet wird in erster Linie die Schnittstelle, nicht das DRAM Array.

Aber wir reden hier von NAS Appliances, da wird der Speicher hoffentlich nicht übertaktet.

 

[MountWalker]

@TomH22

Nicht nur uebertaktete Rechner sind instabil. Stabil ist, wenn Prime95 Blend auch nach einen ganzen Tag noch keinen Speicherfehler hat. Wenn du es unbedingt ueberprueften willst und einen "Beweis" brauchst, weil du vielleicht noch nie davon gehørt hast, kauf dir ein beliebiges, zehn Jahre altes AMD-FX-System mit AMD990X oder 970 Northbridge, stecke es einfach in ein handelsuebliches Gehæuse ohne direkten Luftstrom auf die Northbridge und lass Prime laufen. Nach spætestens 4 Stunden wirst du auch ohne Uebertakten den ersten Speicherfehler haben. Und diese Speicherfehler passieren, obwohl komischerweise weder CPU noch der in die CPU integhrierte Speichercontroller noch die RAM-Module ueberhitzen, sondern ein Bridge-Chip, der nur PCIe und SATA und eine Verbindung zur Southbridge steuert - Hexenwerk, nach Lehrbuch ist das nicht erklærbar, passiert aber und passiert nicht mehr, sobald du einen Blasebalg direkt auf die Northbridge richtest.

Um auf der HDD/SSD zu landen, muessen die Bits aber sowieso den SATA-Controller passieren.