Dateien per SMB auf Mac kopiert belegt 1,6 TB, Datei selbst aber kleiner

[tocotronaut]

hilft das?

Auf der Synology ...
Systemsteuerung > Dateidienste > SMB > Erweiterte Einstellungen > Sonstiges

Aktivieren Sie "Beim Erstellen von Dateien keinen Speicherplatz reservieren"

Da wird auch gesagt, dass mit DSM8 alles besser wird. Das müsste in den nächsten Wochen erscheinen...

 

[AgentMax]

Das ist die falsche Richtung. Es geht ja vom NAS runter.
Das NAS sollte damit nichts zu tun haben. Denn Windows verbindet ja selbst per Netzwerk mit dem Share auf dem Mac.

 

[wuchtbrumme]

@tocotronaut : der TE schreibt, auf der Syno läuft ein virtualisiertes Windows mit einer SMB-Dateifreigabe von einem Mac.

Synology hat da nicht mehr mit zu tun als dass es Host für die VM ist.

In dem Link, der sich in dem versteckt, den Du gepostet hast , steht eine Erklärung zu "allocate", ich poste den noch mal direktt:
https://forums.veeam.com/veeam-agent-for-windows-f33/solved-veeam-backup-to-synology-nas-takes-forever-t63558.html

In dem Link wird erwähnt, dass die Verhaltensänderung (am Beispiel Syno) von UNIX-Allocation auf Windows-Allocation stattfindet, es ist daher davon auszugehen, dass Windows das Verhalten per Default eingestellt hätte. Interessant ist aber, dass Windows in der beschriebenen Konstellation gar nicht Server ist. Hinsichtlich der SMB-Verbindung wäre das ja der Mac. Oder es ist auf dem Mac nicht eingestellt und das Client-OS kann das Feature anfordern (würde mich wundern). Es wird beschrieben, dass es dann zu dem beobachteten Verhalten (Timeouts, zu große Datenmengen) kommen kann, wenn das Ziel-FS nicht gut mit "Extents" umgehen kann, wozu z.B. HFS+ gehöre. APFS wird nicht extra erwähnt (vielleicht ist die man-Page zu alt), aber da es auch von Apple stammt könnte man fast vermuten, dass es das auch nicht kann.

Unglücklicherweise gibt es keinen einfachen Weg, in macOS die Settings für SMB herauszufinden. Aber wenn man die Hypthese weiterspinnt, dass Windows das setzen kann (das Verhalten im anderen Weg ist ja dann auch OK), habe ich mal nach "disable allocation in windows smb" gegugelt und das hier von der KI vorgeschlagen bekommen, "opportunistic locking" zu deaktivieren.

Ich bin aber immer noch mit einem brain knot versehen, weil die Beschreibung sagt, man solle das auf dem Server ausschalten. Also würde ich die Hypthese ad acta legen. Und der brain knot kommt daher, dass man sich kaum vorstellen kann, dass Apple seine Dateifreigabe mit einem Feature konfiguriert ausliefert, das auf seinen FS Probleme machen würde. Du verwendest doch 15.5?

 

[tocotronaut]

Wenn er die Datei aus der SMB Freigabe unter Windows zieht ist ja alles okay.
Aber beim schieben (Win auf NAS -> datei auf Mac kopieren) besteht das Problem.

Synology hat da nicht mehr mit zu tun als dass es Host für die VM ist.

Und der Host hat immer ein Treiberpaket für den Guest -> Netzwerk/Maussteuerung/VNC etc. dabei...
Parallels Tools / Vmware Tools / Virtualbox Guest Additions
und hier die Synology Guest Tools

Möglicherweise! wird der VM-Treiber der Synology SMB zugriffe nach Aussen abfangen so dass Windows an der Stelle raus ist (ohne es zu wissen).
Da bin ich ganz bei @lisanet (wenn ich sie richtig verstanden habe).

Aber das ist alles nur Spekulation - ich habe keine Ahnung wo der Fehler genau liegt...

Windows selbst/alleine macht so einen quatsch *eigentlich* nicht. Das wär uns hier früher aufgefallen.

 

[wuchtbrumme]

und hier die Synology Guest Tools

Möglicherweise! wird der VM-Treiber der Synology SMB zugriffe nach Aussen abfangen so dass Windows an der Stelle raus ist (ohne es zu wissen).
Da bin ich ganz bei @lisanet (wenn ich sie richtig verstanden habe).

sehr guter Gedanke und bei lisanets Hinweis musste ich auch denken, dass das möglich wäre - aber wir sind immer noch dabei, dass die opportunistic locking-Eiinstellung am Server läge (wenngleich seit SMBv3.11 auch shareweise).

Aber das ist alles nur Spekulation - ich habe keine Ahnung wo der Fehler genau liegt...

dem schließe ich mich an. Wenn man mal die SMB-Settings von macOS herausfinden könnte.

Aber @AgentMax könnte ja mal, ganz auf blöd, die Einstellung "opportunistic locking" in der Syno prüfen/ggfls. abschalten und gucken, ob das was täte. Wenn, dann wäre ich baff

 

[OmarDLittle]

Was ist denn der Inhalt einer solchen Datei, die falsch ankommt? Sind das kleinere Videofiles? Passiert das auch mit anderen Arten von Dateien?

Schaue ich mir die Info während des Kopiervorgangs an, sehe ich die „normalen“ Bytes hochzählen, die
1,6 TB sind von Anfang an ersichtlich.

Hast du davon mal eben einen Screenshot? Die Sache ist so seltsam, jede Kleinigkeit könnte einen Anhaltspunkt für die Lösung liefern.

Könnte sein dass es sich um einen Fehler/Bug im Zusammenhang handelt, wenn Windows 11 eine Freigabe von macOS anzusprechen versucht - da Apple erst irgendwann den SMB-Code überarbeitet hat und Microsoft nun das Zusammenspiel mit macOS nicht besonders priorisiert und hier vielleicht nicht ganz kompatibel ist.

Die Synology als Hypervisor sollte mit der Geschichte gar nichts am Hut haben, genau. Da wäre dann auch die Frage, wie du die VM von Parallels dorthin umgezogen hast. Vielleicht ein frisches Win 11 installiert mit der neuesten Version? Welches Win 11 ist das, 24H2? Siehst du mit cmd/win+r und winver.

 

[AgentMax]

Also:

- Die SMB Optionen (das locking) in der Synology zu ändern hilft nicht
- das Format der SSD am Mac zu ändern (von APFS auf ExFat) hat erwartungsgemäß nichts gebracht
- Neustart aller Systeme hat nichts gebracht

Es handelt sich dabei um 10bit 4K 4:2:2 HLG mp4 Dateien dich ich auf dem iPad mit LumaFusion exportiert habe. Da ich die Dateien von unterwegs mit
schlechter Verbindung in mein Heimnetz bringen muss, habe ich folgenden Workflow:
- schneiden der Filme mit Lumafusion
- Exportieren der Filme als mp4 Datei
- zerteilen der Dateien mit Keka auf dem iPad in kleine 50 MB Häppchen (bester Mix zwischen Aufwand und Abbruchverhalten beim Upload)
- Upload dieser Häppchen auf die Synology
- entpacken der Dateien mit WinRAR unter der Windows VM (Hauptaufgabe der VM). Unter macOS hab ich es nicht hinbekommen die
Archive wieder zusammenzusetzen. Daher damals von Unterwegs diese Lösung erschaffen und beibehalten
- das Entpacken passiert direkt auf die Netzwerkfreigabe vom Mac
- auf dem Mac per Safari auf YouTube hochladen

Das direkte Entpacken auf den Share erzeugt diese riesigen Dateien. Entpacke ich lokal in die VM (wollte ich halt vermeiden, da die virtuelle Platte zu vermüllen) und kopiere es dann rüber, geht es.

Ich vermute es liegt irgendwie am entpackverhalten von WinRAR.
Zur Vermeidung entpacke ich jetzt lokal und kopiere es manuell rüber.

 

[tehabe]

Solltest du dann sie nicht wieder mit Keka auf macOS zusammensetzen können?

 

[wuchtbrumme]

Also:

- Die SMB Optionen (das locking) in der Synology zu ändern hilft nicht
- das Format der SSD am Mac zu ändern (von APFS auf ExFat) hat erwartungsgemäß nichts gebracht
- Neustart aller Systeme hat nichts gebracht

Es handelt sich dabei um 10bit 4K 4:2:2 HLG mp4 Dateien dich ich auf dem iPad mit LumaFusion exportiert habe. Da ich die Dateien von unterwegs mit
schlechter Verbindung in mein Heimnetz bringen muss, habe ich folgenden Workflow:
- schneiden der Filme mit Lumafusion
- Exportieren der Filme als mp4 Datei
- zerteilen der Dateien mit Keka auf dem iPad in kleine 50 MB Häppchen (bester Mix zwischen Aufwand und Abbruchverhalten beim Upload)
- Upload dieser Häppchen auf die Synology
- entpacken der Dateien mit WinRAR unter der Windows VM (Hauptaufgabe der VM). Unter macOS hab ich es nicht hinbekommen die
Archive wieder zusammenzusetzen. Daher damals von Unterwegs diese Lösung erschaffen und beibehalten
- das Entpacken passiert direkt auf die Netzwerkfreigabe vom Mac
- auf dem Mac per Safari auf YouTube hochladen

Das direkte Entpacken auf den Share erzeugt diese riesigen Dateien. Entpacke ich lokal in die VM (wollte ich halt vermeiden, da die virtuelle Platte zu vermüllen) und kopiere es dann rüber, geht es.

Ich vermute es liegt irgendwie am entpackverhalten von WinRAR.
Zur Vermeidung entpacke ich jetzt lokal und kopiere es manuell rüber.

Workflows sind ja was zutiefst persönliches und natürlich muss man auch Probleme umschiffen. Aber man liest und staunt Also unabhängig von der 1,6TB-Thematik:

1. So schlecht kann eine Verbindung nicht sein, dass sie Bits ändert. Wenn sie Bits ändert, ist es keine Internetleitung, die für irgendwas tauglich ist, sondern ein Zufallszahlengenerator. Den benutzt man für Lotto
2. Wenn das Problem nur ab und an ein Abbruch ist, was spricht dann gegen ein Programm, was Uploads an der letzten Stelle fortführen kann? WinSCP und FileZilla sollten das beide können. FTP/SFTP für die Syno sollte kein Ding sein.
3. Ein Abbruch? Aber nicht zufällig bei einem L2TP/IPsec-Tunnel? Da gibt es von iOS aus keinen vernünftigen Keepalive. Abhilfe: Z.B. Wireguard _mit_ Keepalive verwenden.
4. In Deiner Beschreibung sprichst Du zwar von Entpacken, aber wo das Einpacken stattfindet kann man nur erraten. Keka? Binäre und vor allem bereits komprimierte Videoströme weiter zu komprimieren ist nicht sinnvoll.

 

[tocotronaut]

Ich vermute es es geht mehr um das zerlegen der großen dateien, das man mit den tools ganz gut erledigen kann...

 

[AgentMax]

Primär geht es darum die Filme mitten auf dem Ozean per Starlink hochgeladen zu bekommen. Ich habe viel probiert, OpenVPN, WireGuard, direktupload aus LumaFusion, Safari auf dem Macbook. Ich glaub FTP oder SFTP waren auch dabei, usw usw.
Mit der o.g. Lösung bin ich erfolgreich gewesen und daher hat sich diese gefestigt.
Wenn dann mal 1 oder 2 50MB Pakete abbrechen, sind die schnell wieder neu gestartet und der Rest ist nicht verloren.
Je nach Output haben die Rohdaten die rüber müssen schon mal 30-40 GB.

4. Packen mit Keka, entpacken unter macOS ebenfalls mit Keka probiert. Brach aber immer ab. WinRAR hat es geschafft. Daher bin ich dann dort geblieben

 

[wuchtbrumme]

ok, dann hast Du ja eine Lösung. Aber wenn Du flexibel bist, schlage ich Dir vor, bei Gelegenheit einfach mal die große Datei mittels sftp reput zu übertragen. Vielleicht als Versuchsballon danach. Bestimmt gibt es auch Programme, die das timen können (vielleicht nicht auf dem iPad).

 put [-afpR] local-path [remote-path]
             Upload local-path and store it on the remote machine.  If the remote path name is not specified, it is given the same name it has on
             the local machine.  local-path may contain glob(7) characters and may match multiple files.  If it does and remote-path is specified,
             then remote-path must specify a directory.

             If the -a flag is specified, then attempt to resume partial transfers of existing files.  Note that resumption assumes that any par‐
             tial copy of the remote file matches the local copy.  If the local file contents differ from the remote local copy then the resultant
             file is likely to be corrupt.

             [...]
     reput [-fpR] local-path [remote-path]
             Resume upload of local-path.  Equivalent to put with the -a flag set.

 

[OmarDLittle]

mitten auf dem Ozean per Starlink

Ach, welch Traum wäre hier zfs send, aber das läuft nur auf MacOS und nicht am iPad und braucht wiederrum eine Empfänger-VM auf der Gegenseite, die die Daten entgegennimmt.