Empfehlungen für einfaches NAS mit schnellem Dateizugriff

[Uridium]

Welches Format hat denn deine NAS HDD? NTFS? Wenn ja, lief das schon immer scheiße unter Linux (was die Leistung angeht). Ist halt nur ein FUSE Format.

Außerdem muss der Netzwerkdienst (Samba, etc) den Cache auch unterstützen, bzw. aktiviert haben. Ein Systemcache bringt dir nichts, wenn der Dienst gezielt direct i/o anfordert, den Cache also von vornherein explizit ablehnt. Das Cacheverhalten kann man ausloten.

 

[storkstork]

snaxilian
Ja die Haken sind in Windows überall ganz unten gesetzt. Sonst würde es wahrscheinlich einiges länger dauern.

Meine Messung sieht so aus: Bei klick auf Eigenschaften im Kopf die Sekunden mitzählen und wenn die Anzahl der Dateien nicht mehr steigt, aufhören zu zählen.

Besten Dank für den Tip mit der Powershell-Eingabe. Ich wusste nicht, dass man sowas machen kann

 

[omavoss]

Falls Dir das Programm nicht zusagt, nimm eine ähnliche Software. Die gibt es wie Sand am Meer ....

Kannst Du bitte ein paar Links zu "wie Sand am Meer" schicken? Vorzugsweise Freeware. Denn das ist ein interessantes Thema, es wird Zeit für ein neues Projekt meinerseits.

 

[Demon_666]

Kannst Du bitte ein paar Links zu "wie Sand am Meer" schicken? Vorzugsweise Freeware. Denn das ist ein interessantes Thema, es wird Zeit für ein neues Projekt meinerseits.

Recherieren werde ich nicht für Dich, denn du kennst deine Anforderungen am besten
Adobe, Ashampoo, Franzis etc. pp haben alle was im Portfolio.

 

[snaxilian]

Danke für den Hinweis, hier mein Versuchsaufbau:

Test erfolgte von einem Win10 Client aus, verbunden per GBit Ethernet und es sind einfach zwei Freigaben auf meinem Selbstbau-NAS, Angabe der Dateien und Ordner dienen zur Größeneinordnung.
Der Client ist ein Laptop mit i7-6600u und 8 GB Ram mit Win 10 Pro 1909 Build 18363.1016.
Das Selbstbau-NAS hat ein Pentium G4600, 32 GB RAM, je einen HDD-Pool und ein SSD-Pool, ZFS als Dateisystem und es laufen noch aktuell zwei kleine VMs. OS + VMs belegen ca 8GB RAM, die restlichen 24GB sind ZFS entsprechend ein read-only Cache je zur Hälfte gefüllt mit am häufigsten und zuletzt genutzten Daten (Blöcken, nicht Dateien). CPU Last ist im Schnitt bei 20% wenn nicht gerade Backups, Replikationen, Scrubs o.ä. laufen, also kein Limit was zum Zeitpunkt der Tests alles nicht lief.
Du siehst: Trotz für ein NAS verhältnismäßig starke CPU und viel RAM und eines für große Datenmengen sinnvollem b-tree basiertem Dateisystems braucht die Auflistung der Eigenschaften und in welchen Unterordnern die Daten liegen "lange" im Sinne von einigen Sekunden mit HDDs und die Hälfte der Sekunden bei SSDs.

@Uridium NAS nutzt ZFS. Der RAM wird entsprechend als ARC verwendet und auch unter Linux gibt es bei so ziemlich jeder Distribution das VFS in dem der page_cache Informationen zu den Dateisystemen enthält. Direct I/O, was auch immer du darunter formulierst, wäre meiner Meinung nach z.B. die Nutzung des NAS als iSCSI Target oder wenn man NFS verwenden würde mit sync=always aber dann ist der NFS Server ziemlich lahm wenn man kein explizites ZIL nutzt. So oder so ist dies nur bei Schreibzugriffen relevant. Ein SSD Read-Cache kann sowohl bei Freigaben per SMB oder NFS als auch bei iSCSI verwendet werden. Ein zugreifendes System kann nicht direkt Daten von den HDDs in dieser (meiner) Situation anfordern da der zugreifende Client davon keine Ahnung hat. Client fragt Server nach Daten, Server bekommt die Anfrage per SMB/NFS/iSCSI und beauftragt sein Storage-Subsystem mit der Antwort. Das guckt zuerst im ARC (also RAM), falls nicht dort dann im L2ARC sofern vorhanden und wenn auch da nicht dann auf den HDDs. Bei Schreibzugriffen geht dies direkt auf die Laufwerke sofern kein eigenes ZIL vorhanden ist. Aber dem TE geht es ja um lesenden Zugriff mit möglichst geringer Latenz.

@storkstork Windows hat, nachdem der Stühle schmeißende CEO weg war, vieles von Linux übernommen oder sich abgeguckt, u.a. ein mächtiges CLI mit dem vieles geht wenn man sich mal damit angefreundet hat was bei mir nicht vollends der Fall war aber ich muss zum Glück beruflich mit Windows nur noch wenig bis nix machen^^

@omavoss https://en.wikipedia.org/wiki/Comparison_of_raster_graphics_editors#Features und dann diejenigen, die eine image library unterstützen.

 

[Uridium]

NAS nutzt ZFS.

Dein NAS meine ich nicht. @halwe nutzt eine externe Platte, die er am "USB3-Port am PC" vergleicht.

Am lokalen USB3-Port am PC habe ich da natürlich eine ganz andere Situation und kann die SSD in Nullkommanix durchforsten.

Und das könnte Windows sein (hat er ja nicht erwähnt), was mit Sicherheit unter NTFS besser abgeht.

Ich würde zuerst von der Shell benchmarken und gucken, was das System lokal leistet (vielleicht mit time tree /mnt/platte) und dann von außen via Netzwerk (ggf. auch ob die CPU überhaupt noch mitspielt). Samba kann schnell zum CPU Killer werden, gerade bei schwachen ARM CPUs.

Ich sehe den Flaschenhals nicht bei irgend welchen Caches, eher bei Samba (oder anderen Netzwerkdiensten), die nicht für solche Fälle optimiert sind, bzw. bei solchen Extremfällen (large folders) entsprechend Waitstates verursachen (ist halt ein zusätzlicher Dienst).

Samba kann evtl. noch optimiert werden (async i/o, stream buffer sizes, case sensitivity, usw). Da gibt es viele Beispiele/Empfehlungen im Netz. Ansonsten gilt NFS, gerade für solche Disziplinen, als die deutlich bessere Alternative.

Direct I/O, was auch immer du darunter formulierst

https://lwn.net/Articles/457667

Ob es in dem Dataflow überhaupt zum Tragen kommt, weiß ich nicht. Natürlich wird "von außen" erst mal nur gelesen. Das heißt aber nicht, dass kein Schreibvorgang involviert ist.

 

[halwe]

Kannst Du bitte ein paar Links zu "wie Sand am Meer" schicken? Vorzugsweise Freeware. Denn das ist ein interessantes Thema, es wird Zeit für ein neues Projekt meinerseits.

Wenn es um eine kostenlose Bildverwaltung unter Windows geht, finde ich die Windows Live Fotogalerie nicht schlecht. Insbesondere, da der größte Teil der Sortier-Merkmale direkt in den auch im Windows Explorer verfügbaren Tags wie Bewertung, Markierung usw. gespeichert wird.

Danke für den Hinweis, hier mein Versuchsaufbau:

Danke für den Hintergrund. Eigenbau NAS. Das krieg ich so natürlich nicht zu kaufen.
Wenn ich es recht überschaue war storkstork der Einzige, der mir Werte zu einem ein kaufbaren NAS angab.

Es ist schon seltsam, bisher dachte ich immer, mein NAS wäre alt oder zu schwach ausgestattet, nun merke ich, dass hier wohl ein grundsätzliches Problem vorliegt. Hab's gerade mal mit meinen beiden Windows-PCs probiert (beide mit SSDs): Selbst dort kriege ich übers Netzwerk keinerlei Cache-Effekte und er zählt die Dateien genauso langsam wie das NAS hoch.

Vielleicht, darauf würde auch der bessere Wert unter Linux bei storkstork hindeuten, liegt es tatsächlich wie von Uridium vermutet am SMB-Protokoll, welches einfach immer am Cache vorbei auf die Platten zugreift. Hab ja noch ftp zur Auswahl, mal seh'n, was das bringt.
Und ja, es war wohl keine gute Idee, die ans NAS angeschlossene USB3-SSD mit NTFS zu formatieren. Leider weiß ich das native Format der eingebauten Festplatte nicht.

 

[Uridium]

es war wohl keine gute Idee, die ans NAS angeschlossene USB3-SSD mit NTFS zu formatieren.

Die o.g. Nachteile von NTFS-3G (ggü. einem nativen Linuxdateisystem) sind wahrscheinlich im Hinblick auf die Einbußen, die Samba (in deinem Fall) mit sich bringt, zu vernachlässigen. Von daher spielt das vermutlich keine allzu große Rolle.

 

[snaxilian]

@halwe Das versuche ich dir ja seit 2 Threads klar zu machen. Du hast falsche Annahmen und Vorstellungen wie Caching-Lösungen im Bereich Storage funktionieren. Was @Uridium meint und verlinkt hat, also direct I/O, zielt wenn ich den Link korrekt gelesen und verstanden habe, auf Schreibzugriffe ab.

Einen weiteren Aspekt der noch nicht betrachtet wurde ist die Frage welche SMB Version das NAS unterstützt. Hier wäre der erste Ansatz mindestens auf SMBv2 zu gehen am NAS da zwischen SMBv1 und v2/3 enorme Verbesserungen gemacht wurden auch hinsichtlich der Performance.
Ein weiterer Versuch wäre die Optimierung des Clients oder diverse Parameter zu testen ob es eine Verbesserung bringt, siehe hierzu: https://docs.microsoft.com/en-us/powershell/module/smbshare/get-smbclientconfiguration?view=win10-ps
Dort gibt es die ein oder andere ggf. interessante Einstellung die man testen könnte.
Weitere Option wäre dann natürlich noch NFS.

Leider weiß ich das native Format der eingebauten Festplatte nicht.

Ich meine mal gelesen zu haben, dass WD wie 98% aller anderen NAS Hersteller auch auf das gute alte ext4 als Dateisystem setzt.

 

[Uridium]

Es wäre auch hilfreich, die 'smb.conf' zu posten. Sie sollte hier liegen: /etc/samba/smb.conf

 

[halwe]

Danke noch mal fürs Dranbleiben.

Ich habe inzwischen herausgefunden, dass das NAS vom Handy aus per SMB2 erreicht wird, dieses Protokoll also grundsätzlich beherrscht.

Ob nun mein Hauptcomputer auch per SMB2 auf das NAS zugreift, weiß ich nicht genau.
Ich habe allerdings mit diesen Informationen auf meinem Zweitcomputer (auch Windows 10) SMB1 deaktiviert (auf meinem Hauptcomputer brauche ich es, um einen alten XP-Computer zu erreichen). Der Zugriff auf den Zweitcomputer ist nun auch ohne SMB1 quasi cachefrei, so dass es wohl nicht daran liegen kann. Ob SMB3 hier eine Verbesserung bringt, kann ich mangels Einstellmöglichkeit nicht ermitteln, bezweifele es aber.

Ich könnte noch mit Hilfe snaxilians Link über
Set -SmbClientConfiguration
probieren, ob sich da etwas optimieren lässt. Das wird ohne weitere Informationen aber auch wieder ein Stochern im Nebel, da bin ich inzwischen natürlich zurückhaltender.

Was kann ich also tun?
Eine SSD hatte ich schon ans NAS angeschlossen - das brachte eher eine Verschlechterung und nach Uridiums Einschätzung liegt es wohl auch nicht am NTFS-System.
Ein neues NAS wird nach obigen Erkenntnissen wohl auch nichts bringen, um meine Dateisammlungen besser im Zugriff zu haben, da letztlich wohl das SMB-Protokoll der Flaschenhals ist und sich selbst zwischen zwei Windows 10 Computern weigert, den Cache des jeweiligen Servers in den Zugriff einzubeziehen.

Vielleicht gibt es noch ein anderes Protokoll, das ich unter Windows einsetzen kann, denn ich kann mir nicht vorstellen, dass im Profibereich, wo die Optimierung vom Server-Systemen mit großem Cache und SSD-Einsatz ein großes Thema ist, der Netzwerkzugriff von so einem Protokoll ausbremsen lässt.

Ansonsten fällt mir nur noch das ein, was ich bei meinem alten Notebook auch schon mal getan habe: Einstellen einer "Offline-Kopie" auf meinem Haupt-PC für die wichtigsten Netzwerkfreigaben. Das kostet mich am Haupt-PC mehr Speicher (mit meiner 500 GB SSD komme ich da nicht weit) und es bringt gelegentlich Sync-Probleme mit sich. Dafür habe ich dann die Netzwerkdateien im schnellen Zugriff und kann sie fürs schnelle Durchsuchen auch noch in die Windows-Dateiindexierung einbinden.

Viele Grüße, Halwe

 

[snaxilian]

Stochern im Nebel, da bin ich inzwischen natürlich zurückhaltender

Warum? Angucken welche Optionen wie gesetzt sind und dann der Reihe nach Änderungen vornehmen, testen und wenn keine Besserung dann wieder auf den Ausgangswert setzen.

Ansonsten kannst natürlich noch NFS anstatt SMB testen, Windows hat einen NFS Client in den optionalen Features.
Da ich nicht mehr im Kopf habe ob du nur von mehreren Endgeräten parallel zugreifst oder nicht wäre ggf. iSCSI noch eine Überlegung wert. Gibt das ein oder andere Paper das iSCSI bei so Tasks wie Directory Listing und dem Umgang mit vielen kleinen Dateien vor NFS und SMB liegt aber der Nachteil ist halt das du es tunlichst vermeiden solltest das iSCSI Laufwerk von mehreren Endgeräten aus parallel zu verwenden bzw. zu beschreiben sonst hast halt Inkonsistenzen.

Ooooooder du siehst endlich ein das deine Anforderungen nach wie vor überzogen und unrealistisch sind.

Du wirst niemals bei einem entfernten Speicher, egal ob SMB, NFS, iSCSI, S3 oder was auch immer, die gleiche Performance erreichen wie bei einem lokalen Dateisystem.

• Lokal: OS greift auf Dateisystem zu, Dateisystem auf Blockdevice. Wenn das Blockdevice dann noch eine NVMe SSD ist geht das noch viel schneller als bei einer Sata SSD.
• Remote dateibasiert: OS greift auf Netzwerkprotokoll zu, Netzwerkprotokoll geht durchs Netzwerk zum NAS/Server, greift dort auf das Dateisystem zu, Dateisystem auf das Blockdevice.
• Remote blockbasiert: OS greift auf Dateisystem zu, Dateisystem auf Netzwerkprotokoll geht durchs Netzwerk zum NAS/Server, greift dort auf das Blockdevice zu.

Egal wie man es dreht und wendet: Jeglicher Remotezugriff ist aufwendiger und komplexer.

Profibereich, wo die Optimierung vom Server-Systemen mit großem Cache und SSD-Einsatz ein großes Thema ist, der Netzwerkzugriff von so einem Protokoll ausbremsen lässt.

Ich arbeite in so einem Bereich. In den allermeisten Fällen werden dort aber nicht mit einzelnen Dateien auf Laufwerken gearbeitet sondern Überraschung mit Datenbanken, die in der Regel für Lesezugriffe entsprechende Mengen RAM haben. Das können klassische mysql/mariadb/postgresql/mssql DBs sein aus denen sich die jeweiligen Anwendungen (DMS für Bestellungen, Rechnungen, etc oder Bildverwaltungs- & bearbeitungssoftware, WWS und/oder CRM, usw. usf) ihre Informationen holen. Webserver haben ihren statischen Inhalt wie z.B. Bilder in Cachinglösungen wie z.B. Redis, memcached oder Varnish. Vereinfacht gesagt steht da im RAM zu jedem Bild oder Datei wo genau diese liegt oder die Dateien selbst liegen im RAM und regelmäßig wird geprüft ob die Datei im Ram und im eigentlichen Storage noch identisch sind. Ergo entfällt bei jedem Aufruf der Webseite oder Anwendung das aufwendige auflisten der Ordner.
Es muss eben nicht mehr der vergleichsweise lange und lahme Weg zum Storage bemüht werden sondern die (lesenden) Zugriffe können näher beim Anwender oder der Anwendung erledigt werden.
Ein wunderbares Beispiel ist da die Webseite Have I been pwned. Gehostet irgendwo in der Azure Cloud aber mit Cloudflare als Cache davor. Im August/Semptember 2018 hatte die Seite circa 32,4 Millionen Anfragen. 32,3 wurden aus den weltweiten Servern von Cloudflare bedient die diese Daten in lokalem Speicher oder Datenbanken vorliegen hatte da dies eben in der Regel nur lesende Anfragen sind (Quelle).

Genau was dort in sehr sehr groß passiert ist vergleichbar mit dem Indexdienst von Windows oder z.B. einer beliebigen Bildverwaltungssoftware wie Lightroom oder Darktable. Es gibt lokal eine Datenbank und sei es nur eine sqlite, in der die relevanten Informationen stehen wie der Speicherort der einzelnen Bilder, Name der Bilder, alle vergebenen Schlagwörter und alle möglichen Metadaten wie Aufnahmedatum und Uhrzeit, welche Kamera und Objektiv etc.pp.

Damit hat man das ganze Thema der Zugriffslatenz vergleichsweise elegant gelöst. Was dann am Ende noch im Bereich Storage übrig bleibt sind Bandbreite und IOPS. Ersteres löst man durch Aufstockung auf 10G und/oder der parallelen Nutzung von Leitungen wie SMBv3 Multichannel oder parallel-NFS ab NFSv4, letzteres durch SSDs sowie beides durch effektivere Zugriffsprotokolle wie dem direkten Zugriff auf Dateien weil man vorher aus zuvor erwähnten Datenbanken und Caches gelernt hat wo genau die Datei liegt anstatt sich durch die Ordner einzeln zu klicken.

 

[Uridium]

Es gäbe z.B. das hier:
https://wiki.samba.org/index.php/Performance_Tuning#Directories_with_a_Large_Number_of_Files

Für weitere Optimierungen brauche ich deine smb.conf.

 

[halwe]

Danke für die weiteren Tipps und Links.
Aber meine Ressourcen für diese Optimierung sind natürlich begrenzt, ohne klare Erfolgsaussicht werde ich keine größeren Kopfstände mehr machen.
@Uridium: Ich nehme an, für eine smb.inf oder smb.conf bräuchte ich einen Systemzugriff auf das NAS, den ich nicht habe.

Die eigentliche Idee war ja, dass ich, wenn ich den Speicher sowieso erweitern muss, auch gleich schaue, ob ich etwas für die Zugriffsgeschwindigkeit tun kann. Das scheint prinzipbedingt so nicht zu funktionieren.

Eine Sache habe ich noch festgestellt: Wenn ich mein altes Notebook (Win 7, SSD) als Server einsetze, erfolgt das Dateizählen von meinem Zweit-PC aus (Win 10, GBit LAN) deutlich schneller als von meinem Haupt-PC (Win 10, WLAN 866 MBit/s) aus (1s statt 5s / 1000 Dateien). Diesen Unterschied gibt es beim Zugriff der beiden Win 10 Computer auf das NAS nicht. Könnte sein, dass das WLAN-Protokoll hier unter bestimmten Umständen auch als Bremse wirkt. Aber ich weiß auch noch nicht genau, ob der Haupt-PC nicht noch per SMB1 zugreift (was ich auf dem Zweit-PC deaktiviert hatte).
Zusätzlich wirkt hier die lokale Indexierung unter Windows 7 auch für Netzwerkzugriffe. Das beschleunigt zwar nicht das Durchzählen, wohl aber das Auffinden von Dateien.
Das Notebook als NAS braucht zwar etwas mehr Strom als die MyCloud (24 W statt 8 W). Dafür kann ich es nachts automatisch schlafen schicken und dann zur Not per Magic Paket jederzeit aufwecken. (Ein Aufwecken direkt per Zugriff funktioniert in meinem LAN leider nicht, da da wohl zu viele Pings unterwegs sind).

Nun habe ich ja durch den Kauf der USB - SSD erst mal ein TB mehr auf dem NAS und damit etwas Zeit gewonnen. Die Beschleunigung der Zugriffe per Offline-Kopie oder eben durch Einsatz des alten Notebooks - das werde ich mir noch überlegen müssen.

 

[snaxilian]

SSH kann man in der Regel sehr einfach aktivieren. Suche ich nach "wd mycloud ssh" zeigt mir $Suchmaschine einige vielversprechend aussehende Treffer...

Wlan unterliegt dutzenden äußeren Einflüssen, die eindeutige und klare Antwort ob dies also einen Einfluss haben kann lautet somit: JA und NEIN.
Das Thema WLAN, Störeinflüsse etc wurde bereits drölfzig mal durchdiskutiert, Forensuche hilft da weiter. Für einen Vergleich mit kabelgebundenem Test aber absolut irrelevant und nicht vergleichbar.

Client und Server handeln beim Aufbau der Verbindung immer aus, welches Protokoll bzw. welche Version sie sprechen und es wird sich in der Regel immer auf das höchstmögliche geeinigt, daher sollte bei deiner Beschreibung egal sein ob SMBv1 noch aktiv ist oder nicht.

 

[halwe]

SSH kann ich im dashboard im Nu aktivieren. Da es der Beschreibung nach aber nur um eine Verschlüsselung des Netzwerkverkehrs geht, sehe ich das eben auch als Stochern im Nebel, warum sollte das Zugriffsgeschwindigkeit bringen? Die Hilfe rät übrigens Netzwerklaien wie mir davon ab, das zu aktivieren.
Ja, ich könnte auch das Netzwerkkabel austauschen, die MyCloud an einen wärmeren Ort stellen oder eben zig Protokollvarianten durchprobieren. Da gibt es unendlich viele Optionen, die noch zu testen wären.
Danke fürs Mut machen Saxnilian, aber weißt du, wenn hier jemand gesagt hätte "Was, ganze 5 s um 1000 Dateien durchzuzählen, das ist unterirdisch!", dann wäre das eine Motivation, noch ein paar Sachen zu probieren. Ich hatte jedoch nirgends den Eindruck, dass ich mit meinen Werten irgendwie deutlich unter dem liege, was ein NAS unter Windows hergibt.

Und ja, ich verstehe, dass meine Alternativen (Offline-Kopie, altes Notebook als Server) unter Profi-Netzwerkern eher ein müdes Lächeln hervorrufen. Was ich heraushöre ist, dass man auf NAS eher große Dateien (Videos, Sicherungskopien) lagert oder eben, sobald es ein paar Dateien mehr sind, eine Datenbank mit eigener Zugriffslogik drumrum baut. Als ob ein Dateisystem nicht schon eine Datenbank wäre.

 

[snaxilian]

SSH ist ein verschlüsseltes Protokoll um auf entfernte Geräte zuzugreifen. Du könntest dies nutzen um dir die smb.conf anzeigen zu lassen. Da man bei einem Zugriff per mit root Account viel kaputt machen kann wenn man nicht weiß was man da macht rät die Hilfe entsprechend davor ab. Der Herstellersupport hat natürlich wenig bis kein Interesse daran, dass sich Anwender melden weil irgendwas nicht mehr geht nachdem diese per root Änderungen gemacht haben aber nicht wussten oder verstanden haben was sie da ändern.

Als ob ein Dateisystem nicht schon eine Datenbank wäre

Nein. Naja vielleicht die allererste Datenbank die ein Praktikant/Azubi oder jemand der mit IT gar nix am Hut hat, mal anlegt ist vielleicht im Ansatz mit einem Dateisystem vergleichbar aber auch nicht mehr.