lemba schrieb:
Im lokalen LAN greife nur ich auf den Server zu d.h. der gleichzeitige Zugriff erfolgt ausschließlich durch das Streamen über Plex über meine Internetleitung (250Mbit down/50Mbit Up). Das NAS ist mit 2,5Gbit an einer Fritzbox 6660 Cable.
also
hust da würde ich mir ja nur begrenzt sorgen machen. Mal angenommen die anderen haben auch nicht mehr als 50 Mbit upload.
Theoretischer Worst case - spoileralarm: da kann die platte schon bremsen
lesend 50 Mbit/s -> 6,25 MB/s, das belastet weder die Platte, noch die Schnittstelle nennenswert. Außer natürlich da liest jemand 1 Byte Dateien in Massen, aber praxisnah fällt das erstmal nicht ins gewicht.
schreibend 250 Mbit/s -> 31,25 MB/s das wäre bei HDDs aus den 90ern schon viel, aber heute? Selbst eine WD30EFRX (alte WD Red 3 TB) schaufelt das schon in 2 kb Blöcken weg. Theoretisch, da kommt noch Overhead fürs Dateisystem drauf, aber andererseits wäre das Schreibzugriff, es kann also gut gecached werden. Bei einer Blockgröße von typischerweise 4k im wahrscheinlich genutzten NTFS auch eher ausreichend.
Wenn du allerdings 2,5 Gbit/s im LAN hast kannst du die Platte selbst auslasten. Theoretische 320 MB/s schafft die eher nicht. Wenn du also gerade die Platte ans limit bringst und dann noch 4 andere irgendwas darauf schreiben/lesen, dann und vermutlich nur dann bremst da etwas. Allerdings immer noch die Platte und nicht die Schnittstelle.
Wenn du entspannt mit 250 MB/s vom NAS lesen und schreiben willst während andere da unter voller auslastung deines Internetanschlusses darauf herumfuhrwerken würde ich empfehlend doch eine SSD zu nehmen, oder die Last mit reichlich cache auf eher 3 als 2 HDDs zu verteilen. keine ahnung ob ein klassisches raid das so problemlos macht, ich würde dann zfs nehmen, 4 HDDs, eine davon parität und 32+ GB RAM, davon 8-16 für den ZFS cache. Dann bremst da wahrscheinlich nichts mehr sofern man nicht wieder theoretische Tests nimmt, oder eben doch mal ein paar millionen 4 kb Dateien von SSD aufs NAS schieben will. Soll ja vorkommen.
edith: also wenn man schon so genau auf die performance guckt ...
es ist wichtig zu unterscheiden was für zugriffe man haben will. schreibende zugriffe kann man wie erwähnt gut puffern um so z.b. die schwäche von HDDs bei kleinstzugriffen durch deren kopfbewegungen auszugleichen. erstmal puffern, dann kann die theoretisch die 256 4 kb Dateien als einen 1 MB großen Block schreiben, problem gelöst. Vereinfacht, aber so in etwa.
lesenden zugriff kann man so aber nicht ausgleichen. da kann man nur gut raten was als nächstes gelesen werden könnte und das schon mal vorrätig halten. Entweder hofft man dass dass gleiche noch mal gelesen wird (afaik windows strategie auch in win10), oder dass bei kleinstzugriffen (einzelne Bits und Bytes) auch die folgenden gelesen werden sollen (strategie bei CPU Caches und RAM, für Massenspeicher eher irrelevant) oder man zählt mit wie oft etwas gelesen wird und hält die Daten auf die am häufigsten zugegriffen wird vorrätig.
ZFS hat den Vorteil dass es sowohl letzteres macht, also auch die zuletzt gelesenen Daten erstmal zwischenspeichert für einen erneuten zugriff. Dadurch ist der Cache robuster als bei z.b. NTFS unter windows, oder ext4 unter ubuntu.
Da du in deinem Usecase aber nur geringfügig (50 Mbit/s) lesenden Zugriff hast, abgesehen von deinem eigenen aus dem LAN heraus fällt das hier praktischerweise nur schwach ins gewicht.
Was bleibt ist dass es der Schnittstelle egal ist ob gelesen oder geschrieben wird.
