Entsprechend einem Forum ist das Problem mit gvfs und cifs viel besser. Ich bin mit diesen Begriffen nicht vertraut, aber ich kann das bestätigen. Indem Sie das Laufwerk manuell montieren:
mount -t cifs -o username=root,password=xxxxx //192.168.0.186/asmedia-hdd /media/asmedia-hdd Ich kann 10MB / s in Nautilus erreichen. Das einzige Problem, dass ich keine Netzwerkerkennung habe und das Laufwerk nicht von Nautilus abmounten kann. Ich denke, das ist keine echte Lösung.
Gibt es überhaupt einen Zwang, den Nautilus zu zwingen, anstelle von gvfs cifs zu verwenden?
Nächster
Ich habe eine Konfigurationsdatei gefunden, die sehr relevant erscheint:
/usr/share/gvfs/mounts/smb.mount
[Mount] Type=smb-share Exec=/usr/libexec/gvfsd-smb AutoMount=false Scheme=smb Ich denke, gvfs ist kein Partitionstyp, es verwendet auch Cifs. Ich schätze, ich kann die Puffergröße der Cifs hier irgendwie einstellen. Ich konnte noch nicht herausfinden, wie das geht.
Laut Wiki handelt es sich bei dem gvfs um ein virtuelles Dateisystem, es kann also auf Cifs gesetzt werden, also hatte ich recht.
Nächster
Ich habe diese Antwort gefunden: https://unix.stackexchange.com/a/44318/126217, indem ich versuche, gvfs vom Terminal einzuhängen. Demnach export $(dbus-launch)ist das vor dem Verwenden eines gvfs-Befehls wichtig. Ich bestätige, dass ich keine gvfs-Befehle vom Terminal verwenden konnte, und ich erhielt nur vage Fehlermeldungen über das Problem.
Ich konnte das Laufwerk manuell mit gvfs mounten:
gvfs-mount smb://WORKGROUP\;root@192.168.0.186/asmedia-hdd Ich konnte die gemounteten Laufwerke auflisten
gvfs-mount -l Drive(0): KINGSTON SV300S37A120G Type: GProxyDrive (GProxyVolumeMonitorUDisks2) Drive(1): ST31000528AS Type: GProxyDrive (GProxyVolumeMonitorUDisks2) Volume(0): data Type: GProxyVolume (GProxyVolumeMonitorUDisks2) Volume(1): system Type: GProxyVolume (GProxyVolumeMonitorUDisks2) Volume(2): Rendszer számára fenntartott Type: GProxyVolume (GProxyVolumeMonitorUDisks2) Drive(2): TSSTcorp CDDVDW SH-222AB Type: GProxyDrive (GProxyVolumeMonitorUDisks2) Mount(0): asmedia-hdd on 192.168.0.186 -> smb://WORKGROUP;root@192.168.0.186/asmedia-hdd/ Type: GDaemonMount Es gibt immer noch nicht viele Informationen über die Konfiguration dieser Laufwerke. Nautilus zeigte das montierte Laufwerk nicht. Dies ist interessant, weil ich den Mount-Befehl in Terminal verwendet habe, in dem das eingebaute Laufwerk in Nautilus auftauchte.
Ich habe den Mountpunkt hier gefunden:
cd ~/.gvfs/smb-share\:domain\=WORKGROUP\,server\=192.168.0.186\,share\=asmedia-hdd\,user\=root/ Ich war in der Lage, aus dem gvfs-Laufwerk eine MKV-Datei zu laden, und ich verwendete sie
watch -- du -h test.mkv Um die Übertragungsgeschwindigkeit zu messen, waren es etwa 4,3 MB / s. Ich habe die gleiche Technik verwendet, indem ich die Geschwindigkeit von cp gemessen habe, als ich den Befehl smbclient verwendet habe. Ich konnte also reproduzieren, was Nautilus im Hintergrund macht. Jetzt muss ich nur noch eine Option hinzufügen, um die Cifs-Puffergröße zu ändern, sofern dies möglich ist.
Fazit:
Am Ende fügte ich der fstab folgendes hinzu:
//192.168.0.186/asmedia-hdd /media/asmedia-hdd cifs rw,workgroup=WORKGROUP,username=root,password=xxxxx,noauto,users,iocharset=utf8 0 0 und verwendet
chmod 4755 /usr/sbin/mount.cifs Weil Nautilus schrieb, dass nur Root das Laufwerk einhängen kann, anstatt die Eingabeaufforderung für das Root-Kennwort anzuzeigen.
Diese Lösung gefällt mir nicht, da Nautilus die Netzlaufwerke auf diese Weise nicht erkennt. Ein weiteres Problem, dass ich allen Benutzern die Berechtigung erteilen musste, dieses Laufwerk zu mounten, und ich musste das SMB-Kennwort angeben, da ich dazu keine Eingabeaufforderung hatte. Die Download-Geschwindigkeiten waren in Ordnung, und auch das Hochladen hat mir gefallen. Durch den Upload erhielt ich falsche Geschwindigkeits- und Dateigrößenberichte von Nautilus, es schreibt am Anfang 120 MB / s, was ständig abnimmt. Durch das Überprüfen der Dateigröße mit einem gvfs-angehängten Laufwerk konnte ich Informationen über die tatsächlichen Geschwindigkeiten abrufen. Es waren ungefähr 10 MB / s.
Ich versuche das mit gvfs zu lösen. Wenn ich das schaffe, werde ich eine Antwort posten, aber bis dahin benutze ich diese cifs-Problemumgehung.
nächstes ~ 2016
Fügte einen Fehlerbericht hier hinzu: https://bugzilla.gnome.org/show_bug.cgi?id=762384 Vielleicht haben sie eine Antwort.
nächste ~ 2017
Laut Gnome-Entwicklern ist dies ein Samba-Fehler. Sie schreiben vielleicht einen Patch, aber es gibt keine Garantie. Die Samba-Entwickler haben sich in den letzten 3 Jahren (2014-17) nicht darum gekümmert, ich bin mir nicht einmal sicher, ob das Projekt beibehalten wird.
hinweis :
Ich habe diese 10MB / s über eine WLAN-Verbindung gemessen. Ich habe einige Messungen über Ethernet mit demselben Odroid XU4 durchgeführt, als ich versuchte, dies zu debuggen. (Das GVFS verwendet libsmbclient, so dass es etwas Ähnliches wie das Aufrufen macht smbget.)
Kopie mit Nautilus (18-19MB / s)
# mount with nautilus on GUI # copy with nautilus on GUI Kopie mit smbget-Standardblockgröße (23-24 MB / s)
# mount with nautilus on GUI smbget -u root -w WORKGROUP smb://192.168.0.186/asmedia-hdd/testfile Kopieren mit Smbget 16K (1-64K) Blockgröße (38-57 MB / s)
# mount with nautilus on GUI smbget -u root -w WORKGROUP smb://192.168.0.186/asmedia-hdd/testfile --blocksize=16777216 Kopieren mit CIFS-Halterung (70-90 MB / s)
# mount in fstab //192.168.0.186/asmedia-hdd /media/asmedia-hdd cifs rw,workgroup=WORKGROUP,username=root,password=...,noauto,users,iocharset=utf8 0 0 # copy with nautilus on GUI Ein offensichtlicher Engpass ist die zu kleine Blockgröße hier in GVFS, aber die Geschwindigkeit liegt bei etwa 1k Blockgröße und erreicht höchstens 63% der CIFS-Geschwindigkeit. Daher muss in der smb lib ein weiterer nicht identifizierter Engpass vorhanden sein.