Geschwindigkeit bei smb Datenübertragung auf NAS (spez.: kleine Files)

[jteschner]

Dann tu das bitte endlich.

Schon getan - kein Thema. Ich kann nur gerade nicht neu booten, da, wie gesagt, das Backup läuft ... und das dauert noch ein paar Stunden (1TB)

 

[jteschner]

Puh. Das Backup läuft immer noch - mit einer Raketengeschwindigkeit von ca 20MB/s (USB zu USB, von meinen Freigaben zu einer über Dock angeschlossenen Seagate Ironwolf 3,5").
So wie ich das sehe (lt. logs) dauert es noch ein paar Stunden (läuft bereits 12h+).

Dann kann ich deine Hilfe endlich in die Tat umsetzen ...

 

[lisanet]

Puh. Das Backup läuft immer noch - mit einer Raketengeschwindigkeit von ca 20MB/s (USB zu USB, von meinen Freigaben zu einer über Dock angeschlossenen Seagate Ironwolf 3,5").
So wie ich das sehe (lt. logs) dauert es noch ein paar Stunden (läuft bereits 12h+).

Dann kann ich deine Hilfe endlich in die Tat umsetzen ...

Das ist echt lange. Da stimmt was nicht oder du machst es auf die ungünstigste Arte via Finder. Das ginge dann vom Synco zum Mac und vom Mac zum Raspi. Und das alles via smb.

Oder was meinst du mit "USB zu USB"?

Am schnellsten wäre gewesen, wenn du das mit rsync gemacht hättest: Entweder mit einem rsync-Server auf der Syno und dann auf der Kommandozeile auf dem Raspi, oder wenn du auf der Syno einen ssh Zugung hast, dann einfach darüber von der Kommandozeile des Rapsi aus.

Oder deine SSD bricht in der Geschwindigkeit nach einiger Zeit ein. oder ne Kombi von beidem: via Finder hin-und-her und der SSD. Wie schon mal erwähnt war mein bisheriges Wissen, dass die Fanxiang eher nen schlechten Ruf hat, eben wegen der einbrechenden Geschwindigkeit bei längeren Schreibzugriffen.

SSD im NAS finde ich eh nicht immer so sinnvoll. Mit dem üblichen Gigabit-LAN reicht die Geschwindigkeit eigentlich jeder modernen USB 3 HDD aus. Besonders dann wenn man ein NAS eher als Datengrab nimmt. Da hat man dann gerade beim schreiben so einen Einbruch der Geschwindigkeit nicht drastisch. Und auch beim Lesen sind da eher selten viele wahlfreie kurze Zugriffe hintereinander notwendig.

Gigabbit-LAN sind ja theoretisch max. 125 MB/s, abzüglich des overhead im Optimalfall dann so ca 90-100 MB/s und das schaffen HDD. Da bringt dann eine SSD darüber hinaus nichts. Nur das Risiko, dass die Schreibwerte nach längerer Zeit einbrechen.

 

[jteschner]

Das ist echt lange. Da stimmt was nicht oder du machst es auf die ungünstigste Arte via Finder. Das ginge dann vom Synco zum Mac und vom Mac zum Raspi. Und das alles via smb.

Oder was meinst du mit "USB zu USB"?

Am schnellsten wäre gewesen, wenn du das mit rsync gemacht hättest: Entweder mit einem rsync-Server auf der Syno und dann auf der Kommandozeile auf dem Raspi, oder wenn du auf der Syno einen ssh Zugung hast, dann einfach darüber von der Kommandozeile des Rapsi aus.

Oder deine SSD bricht in der Geschwindigkeit nach einiger Zeit ein. oder ne Kombi von beidem: via Finder hin-und-her und der SSD. Wie schon mal erwähnt war mein bisheriges Wissen, dass die Fanxiang eher nen schlechten Ruf hat, eben wegen der einbrechenden Geschwindigkeit bei längeren Schreibzugriffen.

Nein, nein.
Ich habe unter omv das USB-Backup installiert und darüber die Backup tasks aufgesetzt: Freigabe -> Backup-Disk.
Das habe ich so gemacht, weil ich die fette 3,5" Platte im "Normalbetrieb" gern abgezogen hätte und in der Schublade lager. Und alles startet automatisch sobald ich die Platte anschließe. Funktionierte auch.
Da läuft ja mWn rsync im Hintergrund wenn ich die Backup Disk einstöpsel - das hat es auch getan und hatte ich mit einer kleinerer Freigabe vorab getestet.
macOS ist da überhaupt gar nicht beteiligt.
Ich kann in omv ja über

Diagnose->Systemprotokolle->Logs->syslog

sehen, was gerade gemacht wird.

 

[jteschner]

Ich bin absolut ratlos: gerade habe ich mal einen kleinen Test gemacht während das Backup noch läuft.
Ich habe mal eine größere Datei vom NAS auf das MBP über smb kopiert: Geschwindigkeit ebenfalls 25MB/s - da stimmt doch was nicht :-/
Es war, als ich es frisch aufgesetzt hatte, ca 70MB/s über smb - zumindest beim lesen.
Entweder liegt es gerade daran, dass da noch das Backup im Hintergrund läuft, ich habe in der Konfig irgendwas falsch gemacht oder es ist ein HW-Thema. Wie gesagt: ich bin ratlos ...
Fehlermeldungen in den logs gibt es jedenfalls nicht

 

[Mel Linus]

teilen sich bei der PI nicht alle USB Ports die Schnittstelle? Generell hast du halt super viele Faktoren, die deine Geschwindigkeit beeinflussen. Z.B. wenn du jetzt das Backup von den vielen kleinen Files machst, leidet die Performance extrem.

Ich würde mal abwarten, bis alle Jobs durch sind und dann nochmal einen Test machen. Wenn dann die Werte immer noch schlecht sind, würde ich gezielt auf Fehlersuche gehen.

 

[lisanet]

teilen sich bei der PI nicht alle USB Ports die Schnittstelle?

yep, das ist es.

Nicht nur die USB-Ports, auch der Ethernet-Port teilt sich die PCI-Lane. Wenn man also via USB to USB was kopiert und dann noch via Ethernet auf die USB-Platte zugreift, wird es eben eng.

Via Ethernet auf USB ist kein Problem, da die 1 PCI-Lane genügend Bandbreite für beides hat. Aber eben ein zusätzliches Kopieren USB - USB macht das ganze eng

@jteschner

ja, USB - USB am Raspi ist suboptimal. Wie oben geschrieben, wäre da ein rsync vom Syno besser gewesen, da dann nur Ethernet-USB vorliegt und eben nicht zusätzlich noch 2 x USB-Datenverkehr durchs Kopieren. Naja, jetzt musst du da leider durch.

 

[jteschner]

So, nun ist das Backup durch - endlich - Speed lt. Protokoll: knapp 19MB/s :-/
Neustart habe ich auch gemacht (schon allein wegen der Plex Geschichte --> plex user in users-group)
Kurzer Test: Plex kann nun auch über mergerfs auf die Unterordner der Freigaben zugreifen - sieht schon mal gut aus. Besten Dank @lisanet für deine Hinweise und Mühen!
Nun muss ich nur noch schauen wie ich damit umgehe, denn Plex hat aktuell die Mediatheken über den anderen, direkten Zugriff (wie lang und breit bereits diskutiert) in der Datenbank. Ich befürchte, wenn ich nun den Pfad zu den Medien-Dateien ändere, dass dann Plex alles wieder neu aufbaut (altes rauswirft, neues wieder rein).

Wegen der Performance der Disks:
tja, da muss ich wohl mal schauen ... weiss nur noch nicht wie ... Tips willkommen
Zusätzlich gerade mal ein kurzes Copy über smb vom NAS zum MBP einer 1,2GB Datei gemacht: 35MB/s - das hat sich praktisch vom ursprünglichen Wert (nach Aufsetzen des NAS) halbiert - unzufriedenstellend

 

[lisanet]

Zusätzlich gerade mal ein kurzes Copy über smb vom NAS zum MBP einer 1,2GB Datei gemacht: 35MB/s - das hat sich praktisch vom ursprünglichen Wert (nach Aufsetzen des NAS) halbiert - unzufriedenstellend

ich weiß, ich wiederhole mich, aber wenn du dir die negativen Kommentare auf amazon zu deiner SSD ansiehst, dann steht dort u.a. dass sie bei größerem Füllstand halt langsamer wird. Hat wahrscheinlich was mit garbage collection zu tun. Warte mal ne Zeit lang ab. Und nochmals wie gesagt: ich habe nur HDD im NAS.

Ach ja...

ich habe die source codes zu vfs_fruit mal gepacht:

Das Problem mit den rwx------ wie in meinem Blog beschrieben habe ich mittlerweile gelöst

Sprich mit nfs_ace=no werden die Rechte gem den diversen mask, modes aus der smb.conf und der acl übernommen und bleiben auch beim zurückkopieren so erhalten und werden eben __endlich__ nicht mehr zu rwx------

Damit funktioniert dann auch das Standard-Zip-Tool des Finders korrekt.

Einziger "Nachteil", der aber bewusst so ist: da nfs_ace=no lassen sich vom Finder aus die Rechte auf dem NAS nicht mehr ändern. Das ist aber eh eine Glaubensfrage, wer ändern darf: Server oder Client.

 

[jteschner]

ich weiß, ich wiederhole mich, aber wenn du dir die negativen Kommentare auf amazon zu deiner SSD ansiehst, dann steht dort u.a. dass sie bei größerem Füllstand halt langsamer wird. Hat wahrscheinlich was mit garbage collection zu tun. Warte mal ne Zeit lang ab. Und nochmals wie gesagt: ich habe nur HDD im NAS.

Hmmm ... ich will da gar nicht gegen reden ... ich hatte es einfach nicht gesehen
Problem:
die Fanxiang 2TB ist inzwischen bei mir zu 75% gefüllt UND sie ist ja neu - ich könnte sie also durchaus "umtauschen"
Nur: dann muss ich praktisch wieder fast von vorn anfangen (zumindest neue SSD rein, Datenbackup einspielen, die Freigaben "umbiegen", ...) --- puh ... ich sehe schon: Pest oder Colera
Aber wenn es nicht anders geht und das das beste wäre ...
Falls ich mich dazu entscheide: deine Empfehlung für eine SSD (Samsung, Kingston, Crucial, ...)? Oder besser gleich 2x2TB bei ca 1,6GB aktuellen Daten (dann Luft nach oben). Ich würde auch ne normale 2,5" drehende Disk nehmen, aber da hatte ich mal bei Amazon geschaut, da gibt es ja kaum noch was, und wenn, dann sind sie kaum preiswerter als gleich große SSDs.

Ach ja...

ich habe die source codes zu vfs_fruit mal gepacht:

Das Problem mit den rwx------ wie in meinem Blog beschrieben habe ich mittlerweile gelöst

Sprich mit nfs_ace=no werden die Rechte gem den diversen mask, modes aus der smb.conf und der acl übernommen und bleiben auch beim zurückkopieren so erhalten und werden eben __endlich__ nicht mehr zu rwx------

Damit funktioniert dann auch das Standard-Zip-Tool des Finders korrekt.

Einziger "Nachteil", der aber bewusst so ist: da nfs_ace=no lassen sich vom Finder aus die Rechte auf dem NAS nicht mehr ändern. Das ist aber eh eine Glaubensfrage, wer ändern darf: Server oder Client.

Toll!

 

[jteschner]

Nun muss ich nur noch schauen wie ich damit umgehe, denn Plex hat aktuell die Mediatheken über den anderen, direkten Zugriff (wie lang und breit bereits diskutiert) in der Datenbank. Ich befürchte, wenn ich nun den Pfad zu den Medien-Dateien ändere, dass dann Plex alles wieder neu aufbaut (altes rauswirft, neues wieder rein).

Plex ist geradegebogen - wie erwartet wurde alle Medien neu eingelesen. Nur meine "Sammlungen", die ich bereits erstellt hatte wurden übernommen - auch was Wert.

 

[picollo]

Meine RapberryPi macht über Finder auch nur ca. 14MB/sek. Nutze ich rsync oder die App SyncTime sind es bis zu 76MB/sek. SSD Samsung T5.

 

[jteschner]

Meine RapberryPi macht über Finder auch nur ca. 14MB/sek.

Da habe ich ja schon Turbogeschwindigkeit mit 35MB/s (große Dateien) - Es waren bei mir aber schon rd 70MB/s über smb MBP<->Raspi-NAS

Nutze ich rsync oder die App SyncTime sind es bis zu 76MB/sek. SSD Samsung T5.

Klingt schon besser

 

[jteschner]

Noch ein paar Tests gemacht, um einzugrenzen ob es an der Fanxiang SSD liegt:
Ich habe "Freigaben" auf der Fanxiang-SSD und auf der Samsung-SSD angelegt (unter Umgehung von mergerfs) und diese dann per smb mit den "üblichen und besprochenen "fruit Parametern" verfügbar gemacht.
Dann eine Videodatei 1,3GB einmal ...
1. von MBP -> Samsung-Freigabe
2. von Samsung-Freigabe -> MBP
3. von MBP -> Fanxiang-Freigabe
4. von Fanxiang-Freigabe -> MBP
kopiert. Also immer lesen und schreiben getestet.

Ergebnis: im Prinzip keine Unterschiede. Immer so um die 30-35MB/s.
Auch ohne die "fruit Parameter" (die habe ich dann mal rausgenommen) - keine Unterschiede im Speed.
Das Einzige, das mir aufgefallen ist: hin und wieder startet die Übertragung mit um die 70MB/s für ein paar Sekunden, dann kommt eine "Gedenkpause" und dann geht es langsamer weiter.
Meine Kenntnisse reichen nicht aus, um das bewerten zu können :-/ aber irgendwie sieht das für mich so aus, als würde ein Cache gefüllt und wenn der voll ist wird die Geschwindigkleit reduziert

Ergänzung: jetzt nochmal getestet, das Ganze im Terminal auf dem Raspi zu machen: die 1,3GB Datei per copy von Fanxiang <->Samsung Ordner kopiert. Geschwindigkeit kleiner als über smb, nämlich < 30MB/s

 

[lisanet]

... das klingt wie USB 2 Geschwindigkeit. Sind es auch ja die richtigen Ports? Nur so als Gedanke.

Keine Ahnung was du wo verbogen hast. Vielleicht ist ja auch nur dein WLAN grottig. Ich mag ein Fritzbox eh nicht, da die das bisher mieseste WLAN bot, das ich jemals hatte. Sogar ein billiger TP-Link war deutlich schneller, stabiler und mit besserer Reichweite am identischen Ort.

Ich habe soeben meine beiden NAS gestestet, jeweils kopieren vom MBA aufs NAS eines 3,8 GB Films, via WLAN 5 GHz

NAS 1 = Raspi + Icybox IB3640SU3 mit 4 WD 3,5" HDD 5400 rpm



NAS 2 = Raspi + DIY Gehäuse + 4 WD 2,5" HDD



Am Raspi / smb / omv kann es also nicht liegen.

Bleibt noch die konkrete Konfiguration, WLAN, SSD vs HDD, Ports und wie immer ... Kabel.

Was anderes kann ich dir nicht mehr sagen. Alle Dinge sind schon mehrmals durchgekaut worden.

Und noch was: ich habe doch schon gesagt, das vfs_fruit nichts mit dem Durschsatz zu tun hat. Du fängst irgendwie immer wieder mit den gleichen Dingen an. Ich versteh ja den Frust, wenn was nicht funktioniert wie beabsichtigt, aber es bringt halt auch nichts, immer wieder irgendeinen Punkt zu bringen in der Hoffnung, dass dann das eine Lösung sei. In diesem Thread und den anderen steht wirklich alles was du wissen musst.

Ich vermute halt eines der obigen (Konfig, SSD, Ports, Kabel, WLAN)

 

[lisanet]

Das Einzige, das mir aufgefallen ist: hin und wieder startet die Übertragung mit um die 70MB/s für ein paar Sekunden, dann kommt eine "Gedenkpause" und dann geht es langsamer weiter.

... miese SSD (das Thema usb_storage und quirks kennst du. Wenn das nicht passt (auf beiden SSD) bricht die Geschwindigkeit ein. Aber auch das hatten wir schon sehr ausgiebig diskutiert)

und auch auch die Sache mit dem write cache bei den Disks (nicht samba) in omv hatten wir schon.

All das sind die Dinge, die das beeinflussen

 

[jteschner]

... das klingt wie USB 2 Geschwindigkeit. Sind es auch ja die richtigen Ports? Nur so als Gedanke.

...

Ich vermute halt eines der obigen (Konfig, SSD, Ports, Kabel, WLAN)

ICH SCHÄME MICH UND GEBE ES ZU!!

Es war USB2 Ich habe beim Einbau des Hubs die Ports am Raspi vertauscht. Wenn es nicht so traurig wäre könnte ich schreien vor lachen ...
Btw: UAS ist aus - hatte ich über die cmdline.txt geändert (mache ich aber noch wie du)
WLAN passt eigentlich
Ich habe zwar keine 80MB/s wie du aber nun immerhin lesend 65-70 und schreibend 50-60

Ich danke nochmals für deine Geduld (die nun bestimmt aufgebraucht ist) und entschuldige mich vielmals für meine Blödheit.
Aber irgendwann sieht man den Wald vor ...

Einen ruhigen Sonntag Abend noch

 

[lisanet]

@ all

So, ich habe das Problem hier erst mal gelöst:

Dann wollte ich per Finder alles wieder löschen: geht nicht. Fehler: Rechte!

Nur das mit dem zip geht nicht

Das war hier

Vermutlich eine ACL in der Art von "group:everyone deny delete" oder ähnlich.

ist nicht direkt der Grund, sondern

Der Auslöser für das Nicht-Löschen-Können des Archivs ist die Kombination von fruit:nfs_aces=yes und der Art wie Samba die effektive Rechte aus Unix und acl ermittelt beim Anlegen von Dateien/Ordnern

Dieses Vorgehen von Samba führt dazu, dass der Ornder "Archiv" mit maximal rw-rw-rw angelegt wird, was dazu führt, dass man den Ordner via Finder nicht mehr löschen kann, da das x-Bit in den Rechten fehlt. ACL sind da also gar direkt beteiligt.

Somit ist es also tatsächlich so und nicht nur "könnte"

Das ganze Problem könnte meines Erachtens an Samba liegen und nicht am Finder / macOS.

Ich habe die letzten Tage die source codes von Samba durchgesehen und das vfs_fruit module gepacht und dabei die beiden Probleme gelöst, das mit nfs_aces=n0 (zurück kopieren liefert rwx------ Rechte) und das mit nfs_aces=yes (Ordner "Archiv" beim entzippen kann nicht gelöscht werden)

Das gepatche Samba läuft hier durchweg stabil und alle Tests, die ich mache zeigen mir bisher keine Nebeneffekte. Eher ist es so, dass das alles stimmiger wirkt.

Ich werde das die nächsten Tage auch mal mit der Apple Implementierung des SMB-Servers vergleichen.

Da das ganze schon recht tief ins System des Samba-Servers eingreift, ist es kein Thema, das hier im Forum zu erklären. Ich könnte maximal das kompilierte Modul bereit stellen für den Raspi. Aber auch das erfordert von denen, die es wollen gute Kenntnisse im Terminal auf dem Raspi.

Ich werde, wenn meine Tests alle durch sind, versuchen, die Patches in die offizielle Samba-Versionen einzubringen und dem Samba-Team senden. Das kann aber noch etwas dauern.

 

[picollo]

Ein großes Lob. So ein Aufwand muss gewürdigt werden

 

[jteschner]

Ich finde das super -- aber wie du dir vorstellen kannst eine Nummer zu groß für mich (zumindest noch).
Morgen werde ich endlich mal dein kleines Script ausprobieren - heute habe ich mich mal um "tägliches automatisches Backup" meiner wichtigsten Daten von OMV zur Synology gekümmert (und erfolgreich implementiert). Jetzt sichert OMV automatisch auf die Syno und diese einmal am Tag nach C2 nach Frankfurt.
Ist ja auch schon mal was .

Nebenbei: nun habe ich das "Problem", dass ApplePiBaker die sd-karte vom omv-Raspi nicht mehr akzeptieren will und ich somit kein Image davon mehr anlegen kann - morgen forsche ich weiter und gebe das mal evt an den Entwickler ...