GNOME Bugzilla – Bug 771022
Add server-side copy support
Last modified: 2018-09-21 18:01:42 UTC
I got several shared volumes on my FreeNAS system. When I copy some files from a volume to another one on the same remote system through Nautilus (beign logged in per ssh or cifs), data transmission is done at 2 MB/s. So obviously the data is piped through my machine and back to FreeNAS. If I execute this mv/cp command on the remote shell, it is done way faster. Would it be possible executing such commands directly on the remote machine, if both volumes are on the same host?
We just do the g_file_copy (gfile) so I believe this is gvfs
This is not indeed a problem in Nautilus. There is already a bug for SFTP, see Bug 518409. There isn't probably any bug for SMB yet, so use this for it. It seems that the following patch has been merged recently: https://lists.samba.org/archive/samba-technical/2015-April/106734.html So the remote copy operation is supported by libsmbclient, but it seems it is not thread-safe, which is a problem...
Created attachment 335616 [details] [review] smb: Add initial remote copy support Copying is slow currently, because read and write fallback is used for it. Implement native copy support with usage of the recently added support in libsmbclient in order to speed up copying.
Created attachment 335617 [details] [review] smb: Run remote copy in another thread Copying blocks main thread, so the backend is unresponsive during the copy operation. Let's move the copy operation on another thread.
Created attachment 335618 [details] [review] smb: Add separate context for remote copying Let's create a separate context for the copy operation, because libsmbclient is not thread-safe.
Created attachment 335643 [details] [review] smb: Add initial remote copy support Server-side copy support has been added in libsmbclient quite recently: https://lists.samba.org/archive/samba-technical/2015-April/106734.html Copying is slow currently, because read and write fallback is used for it. Implement native copy support with usage of the recently added support in libsmbclient in order to speed up copying.
Created attachment 335644 [details] [review] smb: Run remote copy in another thread Copying blocks main thread, so the backend is unresponsive during the copy operation. Let's move the copy operation on another thread.
Created attachment 335645 [details] [review] smb: Add separate context for remote copying Let's create a separate context for the copy operation, because libsmbclient is not thread-safe: https://lists.samba.org/archive/samba-technical/2015-April/106935.html
Created attachment 335646 [details] [review] smb: Handle cancellation of the copy operation properly Return "Operation was cancelled" instead of "Invalid argument", which is returned currently.
See relevant discussions: https://mail.gnome.org/archives/gvfs-list/2016-October/thread.html https://mail.gnome.org/archives/gvfs-list/2016-November/thread.html Ross, any progress on it?
Created attachment 343714 [details] [review] smb: Add separate context for blocking operations A separate context is needed for blocking operations (i.e. copy, push, pull), because the operations block main thread and libsmbclient is not fully thread-safe, see: https://lists.samba.org/archive/samba-technical/2015-April/106935.html
Created attachment 343715 [details] [review] smb: Add initial remote copy support Server-side copy support has been added in libsmbclient quite recently: https://lists.samba.org/archive/samba-technical/2015-April/106734.html Remote copying is slow currently, because read and write fallback is used for it. Implement native copy support with usage of the recently added support in libsmbclient in order to speed up remote copying. Unfortunatelly, you have to add the following in your smb.conf, otherwise it will be slow as before: [global] client max protocol = SMB3 client min protocol = SMB3
I've revamped the patches a bit, but I've realized unfortunately that libsmbclient segfaults also with separate contexts (as was mentioned by Ross on the mailing lists) :-(
Created attachment 343718 [details] backtrace gvfs-copy smb://192.168.127.1/oholy/Downloads/Fedora-Workstation-Live-i386-24-1.2.iso smb://192.168.127.1/oholy/Downloads/smazme.iso & gvfs-ls smb://192.168.127.1/oholy The following is printed from libsmbclient: Freed frame ../source3/libsmb/clireadwrite.c:1052, expected ../source3/libsmb/clirap.c:865. gvfs-ls smb://192.168.127.1/oholy The following is printed from libsmbclient: ../source3/libsmb/clirap.c:809: Type mismatch: name[NULL] expected[struct cli_qpathinfo2_state] And the backend aborts...
See: https://bugzilla.samba.org/show_bug.cgi?id=11413
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gvfs/issues/286.