BigSur: Probleme bei großen Daten zum NAS kopieren

Diese Maßnahmen habe ich allesamt schon probiert, leider ohne Ergebnis. Das Problem kursiert in diversen englischen Foren und ist offenbar auch bei Apple bekannt... Bis dahin: NFS ;)
 
  • Gefällt mir
Reaktionen: dg2rbf
Diese Maßnahmen habe ich allesamt schon probiert, leider ohne Ergebnis. Das Problem kursiert in diversen englischen Foren und ist offenbar auch bei Apple bekannt... Bis dahin: NFS ;)
Dann scheint es aber an deiner NAS zu liegen. Ich habe hier zwar kein NAS sondern einen Raspi 4 der als Fileserver fungiert. Damit habe ich keine Probleme mit SMB, es ist flott und stabil wie eh und je.

Was mir noch einfällt, ist, dass ich auch am iMac signing / encrypting deaktiviert habe, wobei das ja durch den Server nicht mehr erforderlich ist. Das war vor Big Sur.

Dass es mit SMB (besser gesagt mit der Samba-Implementierung) an einer Stelle etwas unglückliche Voreinstellungen gibt, lässt sich aber auch lösen. Das ist aber ein anderes Fehlerbild ("Das Original xxxx konnte nicht gefunden werden") Such mal nach msdfs hier im Forum. Ich habe dazu schon mehrmals gepostet.
 
Zuletzt bearbeitet:
Es scheint kein grundsätzliches Problem zwischen iMac 2017 mit aktuellen BS und DS218 via Fritzbox und SMB Protokoll zu sein.
Ich wollte es wissen und habe eben 700GB fehlerfrei via Drag & Drop mit dem Finder kopiert.
 
Es scheint kein grundsätzliches Problem zwischen iMac 2017 mit aktuellen BS und DS218 via Fritzbox und SMB Protokoll zu sein.
Ich wollte es wissen und habe eben 700GB fehlerfrei via Drag & Drop mit dem Finder kopiert.
Kopieren ist auch an sich kein Problem. Es ist nur gähnend langsam :)
 
Probiert mal das delayed_ack auf dem Mac auf 2 zu setzen (Standardmäßig auf 3 seit mind. SL)

Code:
sudo sysctl -w net.inet.tcp.delayed_ack=2

Wenn's was gebracht hat, wie bei mir, und die Einstellung einen reboot überleben soll:

Code:
echo "net.inet.tcp.delayed_ack=2" | sudo tee -a /etc/sysctl.conf
 
Kopieren ist auch an sich kein Problem. Es ist nur gähnend langsam :)
War das nicht der Auslöser?
"Wenn ich jetzt aber meinen Ordner "Mobile Sync" (ca. 6GB) noch manuell auf die NAS kopieren möchte, geht das ca. 15 min gut und dann kommt eine Fehlermeldung."
 
Dann scheint es aber an deiner NAS zu liegen. Ich habe hier zwar kein NAS sondern einen Raspi 4 der als Fileserver fungiert. Damit habe ich keine Probleme mit SMB, es ist flott und stabil wie eh und je. (...)
Nun ja, vor dem Upgrade auf Big Sur war das mit meinem iMac auch wunderbar performant. Auf dem NAS (Helios64) habe ich nichts verändert, weshalb ich jetzt auch nicht davon ausgehe, dass dort der Fehler liegen kann, sondern bei SMB und macos Big Sur liegen muss. Ich habe auch einige englische Foren quer gelesen, aber noch fehlt der entscheidende Hinweis, wo man schrauben muss. Bin momentan unterwegs, vielleicht schaffe ich es das kommende Woche, mich genauer damit zu befassen.
 
Nun ja, vor dem Upgrade auf Big Sur war das mit meinem iMac auch wunderbar performant. Auf dem NAS (Helios64) habe ich nichts verändert, weshalb ich jetzt auch nicht davon ausgehe, dass dort der Fehler liegen kann, sondern bei SMB und macos Big Sur liegen muss. Ich habe auch einige englische Foren quer gelesen, aber noch fehlt der entscheidende Hinweis, wo man schrauben muss. Bin momentan unterwegs, vielleicht schaffe ich es das kommende Woche, mich genauer damit zu befassen.
auch bei mir war direkt nach dem update SMB langsam, bis ich dann eben signing / encrypting auf dem Server deaktiviert habe.

Und die Sache mit dem Nicht-Einlesen der DS-Store Dateien (aus dem Apple Support Dokument) mache ich eh schon seit Jahren und prüfe das nach jedem Update.

Ob dann zusätzlich das von mir angesprochene msdfs noch dazu beiträgt, habe ich noch nicht analysiert. Es war die Behebung des Fehlers mit dem "Original xxx konnte nicht gefunden werden". Wenn man aber einen derartigen Fehler (der eindeutig auf Serverseite liegt) ausschaltet, dann kann das durchaus die Performance positiv beeinflussen, da keine Timeouts abgewartet werden müssen um dann eventuell Fehler-Abfangroutinen zu starten.

Mehr kann ich nicht anbieten. Bei mir ist SMB performant.
 
  • Gefällt mir
Reaktionen: bundu
@lisanet Bin ich auch dankbar, exerziere ich gerne durch, wenn ich wieder im Büro bin. Und dann melde ich mich, wie es aussieht.
 
In deinem Screenshot steht aber das afp Protokoll verwendet wird nicht das SMB Protokoll / Big Sure unterstützt nur höre SMB versionen aber nicht mehr SMB 1 schau mal in den Einstellungen vom NAS welche SMB version dort aktiviert ist.

Versuche dich mal über das SMB Protokoll zu verbinden Mit Server verbinden und dann smb://ip oder nasname
 
Ist schon ein bisschen was her, aber ich bin nun weg von SMB und nutze ausschließlich AFP im Zusammenspiel mit Openmediavault. SMB konnte ich mit meiner Hardware leider nicht zu einem performanten Arbeiten überreden ;)
 
  • Gefällt mir
Reaktionen: dg2rbf
Eigentlich müsste es genau anders herum sein …
 
Ist schon ein bisschen was her, aber ich bin nun weg von SMB und nutze ausschließlich AFP im Zusammenspiel mit Openmediavault. SMB konnte ich mit meiner Hardware leider nicht zu einem performanten Arbeiten überreden ;)

du solltest aber echt versuchen, SMB zu nuzten. SMB ist im Grunde schneller als AFP.

Was hast du denn schon alles so probiert? Wie betreibst du das NAS? Soft-RAID, mergerfs, snapRAID oder was nimmst du? Auf welchem Rechner?
 
du solltest aber echt versuchen, SMB zu nuzten. SMB ist im Grunde schneller als AFP.

Was hast du denn schon alles so probiert? Wie betreibst du das NAS? Soft-RAID, mergerfs, snapRAID oder was nimmst du? Auf welchem Rechner?
Ich bin damit tatsächlich für die nächste Zeit durch. Diverse Tests sehen SMB auch nur marginal "vorne", weshalb ich jetzt einfach keinen Nerv habe, irgendwo rumzuflicken.

Ich selbst setze ein headless Helios64 System ein, also Armbian und darauf dann OMV und MergerFS mit Luks und SnapRaid. In den Samba Einstellungen habe ich bei dem NAS quasi alles durch und auch auf dem iMac soweit alles probiert (wie packet signing aus, etc.).
 
  • Gefällt mir
Reaktionen: dg2rbf
Ich selbst setze ein headless Helios64 System ein, also Armbian und darauf dann OMV und MergerFS mit Luks und SnapRaid. In den Samba Einstellungen habe ich bei dem NAS quasi alles durch und auch auf dem iMac soweit alles probiert (wie packet signing aus, etc.).

naja, wenn du schon alles durch probiert hast, ...

Ich habe hier als "Zweit-NAS" einen Raspi 4 mit OMV laufen mit 4 USB 2,5 HDD mit mergerfs. Und ich kann mit Samba überhaupt nicht klagen. Was ich sehe, ist ein Unterschied zwischen Shares die jenseits von mergerfs liegen und mergerfs-shares. Und die reine Samba-Performance ist knapp an der max. Grenze für Gigabit LAN. Ich habe auch einen M1, so dass es nicht an macOS liegen kann.
 
  • Gefällt mir
Reaktionen: bundu
@lisanet klingt gut. Mein MBA M1 ist tatsächlich auch recht lahm mit SMB. Interessehalber, aber ein bisschen OT: welche Konfiguration hast Du denn in OMV unter SMB auf dem Raspy? Gerne auch via PM, falls das hier ein bisschen zu OT wird 😉
 
Ich finde nicht, dass das OT ist, wenn ich zum Thema über Probleme bei Kopieren aufs NAS, eine Lösung für ein Eigenbau-NAS schreibe (vielleicht schreibe ich das auch nochmals ausfürhlicher in meinem blog)

Also hier mein setup / config meines "Zweit-NAS"

- Raspi 4 mit 4 GB RAM und vier 2,5" Zoll HDDs
- die HDD haben unterschiedliche Gößen und sind am Raspi über USB 3 mittels eines aktiven USB 3 Hubs (zwecks Stromversorgung der Platten) angeschlossen
- System: Raspian 10 ( also basierend auf Debian buster)
- openmediavault 5

Die HDDs haben 2 TB, 1,5 TB und 2x 1 TB. Daher kam mergerfs in Frage. Da dieses NAS nur als ZweitNAS dient für mein QNAP und als zweites TimeMachine-Ziel (im Wechsel mit dem QNAP) und mir Platz und Geschwindigkeit wichtiger als Ausfallsicherheit ist, habe ich snapRAID nicht heran genommen. Ich habe auch keine Verschlüsselung mit LUKS implementiert.

Beides, snapRAID und LUKS, würde zudem den Rapsi schon deutlich fordern.

Ich habe das Paket mergerfs-folders genommen, damit ich (nur) Ordner über mergerfs zusammenfassen kann und nicht die gesamten Platten zusammenfassen muss. Grund dafür war, dass ich TimeMachine auf einer physischen Platte haben will und nicht durch mergerfs irgendwann auf alle Platten aufgeteilt werden soll (TimeMachine legt ja ein sparsebundle an, was intern auf lauter einzelnen Dateien (= bands) besteht). So hätte ich beim Ausfall einer anderen Platte noch Zugriff auf das TimeMachine-Backup.

Also:
- die 4 HDD mit vier Ordnern versehen (data1 - data4) und diese 4 Ordner mit mergerfs zusammen fassen und darin dann eine Freigabe via Samba einrichten
- auf der größten HDD einen weiteren Ordner in Root-Verzeichnis einrichten und den via Samba als TimeMachine-Ziel freigeben.

mergerfs-folders ist wie folgt konfiguriert:

Policy: most free space
Options: allow_other,cache.files=off,use_ino,dropcacheonclose=true,cache.statfs=60,cache.attr=10,cache.entry=10
disable-x-systemd: deaktiviert (=Standard)

Der Samba-Server selbst ist wie folgt konfigiert:

Bei den Advanced Settings:

use sendfile und async I/O aktivieren und in den extra options:
Code:
min receivefile size = 16384
write cache size = 524288
getwd cache = yes
server min protocol = SMB2
smb encrypt = off
client signing = off

Bei den shares habe ich in der GUI die üblichen Einstellungen aktiviert und die zusätzlichen Optionen aber via environment Settings hinzu gefügt, da das die eigentlich zu bevorzugende Vorgehensweise ist und auch künfitge updates auf OMV 6 überstehen wird.

Für sind das dann folgende settings, die du wie so setzt:

Code:
sudo omv-env set OMV_SAMBA_SHARE_VFSOBJECTS "catia fruit streams_xattr"
sudo omv-env set OMV_SAMBA_HOMES_VFSOBJECTS "catia fruit streams_xattr"

und damit die Shares auch etwas Mac-typischer von Avahi announciert werden, gleich noch:

Code:
sudo omv-env set OMV_SAMBA_ZEROCONF_NAME "%h"

Damit OMV das nutzt (das dauert einige Zeit, also geduldig sein)

Code:
  sudo omv-salt stage run prepare
  sudo omv-salt stage run deploy

und nun noch OMV neu starten.

Mit diesem Setting erziele ich bei Schreiben einer 4 GB großen Datei ca 85-90 MB/s und beim Lesen ca 95-105 MB/s (lt. Aktivitätsanzeige)

Edit:
Das Ganze ist dann in einem schwarzen Plexi-Glas-HDD-Rack verbaut. Lediglich der Hub hängt dann hinten ewa unglücklich dran, verschwindet aber gut hineter der Schreubtisch-Kante. Hier drei Fotos dazu:

IMG_2527.jpgIMG_2529.jpgIMG_2528.jpg

ich sehe gerade, dass "client signing" auch entfallen kann, da das bei SMB2/3 eh nicht deaktiviert werden kann.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: bundu, roger.rebel und dg2rbf
Zurück
Oben Unten