CIFS Übertragung verdammt langsam

[3P945DTYTM]

Hallo,
ich habe mein NAS via CIFS über /etc/fstab eingebunden und kann auch wunderbar darauf zugreifen. Gerade wollte ich einen Ordner mit 10 MiB vom NAS auf meinen Rechner (SSD) ziehen...
Die Übertragungsgeschwindigkeit sinkt immer weiter, aktuell auf 5,1 kiB/s.

Das NAS ist über Gigabit LAN verbunden, sollte also entsprechend in wenigen Sekunden erledigt sein. Sowas hatte ich unter Windows noch nie. Es läuft auch kein Download o.Ä. im Hintergrund.

Wo fängt man denn hier am besten mit der Fehlersuche an?
Ich habe absolut keine Ahnung wo ich ansetzen soll...

[king-crash]

Hier ein paar Ideen:

- Im Fehlerspeicher der NAS schauen ob dort eine Platte Probleme macht.
- Mit dd eine Testdatei erstellen ( dd if=/dev/zero of=/platz/auf/nas bs=1M count=1000 oflag=direct status=progress )
- Falls verfügbar per Webfrontend der NAS die Datei wieder laden und die Geschwindigkeit beobachten.
- Mit der mountoption "-o vers=" experimentieren.

[3P945DTYTM]

Ich glaube nicht dass es am NAS liegt.
Die Festplatten sehen alle gut aus und unter Windows hatte ich nie Probleme gehabt.

Vielen Dank für den Tipp mit der SMB version, damit werde mich mal rumprobieren.
Aktuell sieht der Eintrag folgendermaßen aus:

Code: Alles auswählen

//192.168.xxx.xxx/home        /home/user/nas/home       cifs    credentials=/home/user/.xx-smb,user,noauto,nofail 0 0

[king-crash]

Ruhig auch das dd vom Linux client aus ausführen und testen.
Ich hatte erst vor kurzem das Problem, dass cp recht langsam von einem share kopiert hat ( allerdings ejer mit 20MB/s) und dd in Verbindung mit der Blockgrößenangabe das dramatisch verbessert hat.
Also in deinem Fall "dd if=/dev/zero of=/home/user/nas/home/testdatei bs=1M count=1000 oflag=direct status=progress"

[3P945DTYTM]

Also in deinem Fall "dd if=/dev/zero of=/home/user/nas/home/testdatei bs=1M count=1000 oflag=direct status=progress"

Das lief in ein paar Sekunden mit 104 MB/s durch.
Die Datei konnte ich anschließend über das Webinterface auch in angemessener Geschwindigkeit herunterladen.
Wenn ich die Datei aber per Drag&Drop aus Thunar auf meinen Desktop ziehen will, passiert erst mal ca. 10 Sekunden nichts, dann lief es aber auch in einigen Sekunden durch.

Das Problem scheint also nur manchmal aufzutreten... komisch.

[king-crash]

Ja, exakt mit Thunar hatte ich auch schon Probleme...

[reox]

Also in deinem Fall "dd if=/dev/zero of=/home/user/nas/home/testdatei bs=1M count=1000 oflag=direct status=progress"

Das lief in ein paar Sekunden mit 104 MB/s durch.

compression? Bei sowas immer besser eine Datei aus /dev/random erstellen und auf der festplatte/ramdisk ablegen.
Die Datei sollte auch größer sein als alle caches die irgendwo dazwischen hängen.

[MSfree]

compression?

Welche Kompression? Im Ethernet und WLAN wird nichts komprimiert.

Die Datei sollte auch größer sein als alle caches die irgendwo dazwischen hängen.

Wo hast du den Blödsinn her?

Für eine eindeutige Messung muß man halt Buffers und Caches vorher leeren:

Code: Alles auswählen

echo 3 > /proc/sys/vm/drop_caches

[ChoMar]

Wo hast du den Blödsinn her?

Für eine eindeutige Messung muß man halt Buffers und Caches vorher leeren:

Der "blödsinn" macht für solche Platten /NAS-Tests ziemlich viel sinn. Wenn ich alle Caches vorher leer mache und ne kleine Datei teste dann teste ich die Geschwindigkeit vom Cache, nicht von der Festplatte. Dann flutscht meine kleine Datei einfach so durch, aber wann sie letztendlich auf der Festplatte ankommt weiß ich immernoch nicht und bei größeren Sachen gibts dann Probleme. Deswegen sollte man immer sicherstellen, das man mit mehr Testet als gecached werden kann. Ich will ja schließlich die Dauerperformance testen und nicht das kurzfristig mögliche Maximum. Ausser, ich brauche nur kurzfristig hohe Geschwindigkeiten und keine längeren Zugriffe (nicht das typische Anwendungsspektrum für ein NAS, aber gibt es sicher auch Usecases für.)

[MSfree]

Der "blödsinn" macht für solche Platten /NAS-Tests ziemlich viel sinn. Wenn ich alle Caches vorher leer mache und ne kleine Datei teste dann teste ich die Geschwindigkeit vom Cache, nicht von der Festplatte.

Code: Alles auswählen

hdparm -F /dev/sdX

löscht den Cache einer Platte.

In diesem Fall, wo die Datenrate auf 10kByte/s zusammengebrochen ist, spielt der Cache aber überhaupt keine Rolle.

[reox]

compression?

Welche Kompression? Im Ethernet und WLAN wird nichts komprimiert.

Was weiß ich worüber das geht... Wenn der Fehler ist "datei geht langsam - /dev/null geht schnell" sollte man immer schauen ob die nullen wirklich alle einzeln übertragen worden sind.

Die Datei sollte auch größer sein als alle caches die irgendwo dazwischen hängen.

Wo hast du den Blödsinn her?

Für eine eindeutige Messung muß man halt Buffers und Caches vorher leeren:

Code: Alles auswählen

echo 3 > /proc/sys/vm/drop_caches

Äh - das erschließt sich doch von selber. Wenn ich eine Datei kopiere die kleiner ist als der kleinste Cache der irgendwo dazwischen liegt, merkst du nicht die Datenrate auf die Platte sondern nur in den Cache.
Weißt du ob nicht irgendwo was gecached wird? Zudem muss du die caches auf beiden Geräten abdrehen - oder einfach volllaufen lassen.
Bei meinem NAS macht es einen Unterschied ob ich eine 64MB Datei zum Speedtest nehme oder 1GB.

[wanne]

Welche Kompression? Im Ethernet und WLAN wird nichts komprimiert.

Natürlich wird da komprimiert, wenn du CIFS drüber fährst.

Code: Alles auswählen

hdparm -F /dev/sdX

Hilft dir nur nichts, weil 90% der Platten sich nicht mehr dran hält.

Für eine eindeutige Messung muß man halt Buffers und Caches vorher leeren:

Code: Alles auswählen

echo 3 > /proc/sys/vm/drop_caches

Löscht dir keine Caches auf Serverseite.

Zum eigentlichen Thema: Denke nicht dass du das behoben bekommst. Das ist eigentlich üblich, dass SMB-Verbindungen ohne jeglichen Grund einbrechen.

[king-crash]

Zum eigentlichen Thema: Denke nicht dass du das behoben bekommst. Das ist eigentlich üblich, dass SMB-Verbindungen ohne jeglichen Grund einbrechen.

Bei mir war es eigentlich jedes mal so, dass sich mit dd und entsprechender Blockgröße nahezu das Maximum an Bandbreite des Adapters herauszuholen war.
Wie übrigens beim TE auch (5.Post).

[3P945DTYTM]

Zum eigentlichen Thema: Denke nicht dass du das behoben bekommst. Das ist eigentlich üblich, dass SMB-Verbindungen ohne jeglichen Grund einbrechen.

Was wäre denn das bessere Protokoll für Linux Server <-> Linux Desktop?
NFS?

[wanne]

Was wäre denn das bessere Protokoll für Linux Server <-> Linux Desktop?

Die Frage ist, was du willst: Wenn du wirklich nur einen Client hast: iSCSI. (Bedenke, dass du dann nur mit einem Client zugreifen kannst. )
Ansonsten funktionieren die ganzen verteilten Dateisysteme deutlich besser. Die sind leider aber auch ein ganz anderer Administrationsaufwand.
Zuletzt: Bei bis zu 1gbit/s kannst du meist auch sshfs nehmen. Wenn deine CPU schnell genug ist (im Sinn von Singlecoreperformance), ist das echt flott. Zum reinen Download benutze ich gerne schlicht https.
In meinen Benchmarks macht sich FTP bei großen Dateien meist am besten. Das gilt im allgemeinen aber nicht mehr als Zeitgemäß.

[king-crash]

Bei großen Dateien funktioniert aber auch CIFS gut...
Zumindest bei meinem 1Gbit Setup und wohl auch beim TE.