** Description changed: Ubuntu 18.04 LTS here, fully updated (as of late Jan 2020). TEST #1: To establish a baseline/expected behavior, we first mount an SMB share via mount.cifs and time an ls command: $ sudo mount -t cifs -o username=pablo //myserver.example.com/share ~/mnt/share $ cd ~/mnt/share/some/dir $ time ls ... approx 320 files ... real 0m1,080s user 0m0,008s sys 0m0,005s $ sudo umount ~/mnt/share - TEST #2 + TEST #2 Now we do the same via gio mount: - $ gio mount smb://myserver.example.com/share + $ gio mount smb://myserver.example.com/share cd /run/user/1000/gvfs/smb-share\:server\=myserver.example.com\,share\=share/some/dir $ time ls ... same 320 files ... real 0m28,999s user 0m0,013s sys 0m0,032s Enumeration of files is about 29 times slower when mounted via gio mount than via mount -t cifs. TEST #3 Now for the real weird: while using the gio-mounted folder, we now time ls IN COMBINATION WITH SOMETHING ELSE (can be strace ls, ls|wc etc...): $ time ls | wc - 321 323 9804 + 321 323 9804 real 0m0,546s user 0m0,006s sys 0m0,004s Note that this is almost TWICE AS FAST than the "fast" mount of test #1 and about 53 times faster than "slow" test #2 ! The expectation is that Tests 1 and 2 should have similar timings, not differing by a factor of 30 or so. More disturbing, there is no good reason why tests 2 and 3 differ by an even bigger factor of 53: They use the same underlying infrastructure which test 3 proves is adequately fast. And yet, we get this slow down in test 2. As a final note, these benchmarks are a distilled version of the original real-life motivating scenario where a Java-based program would simply take tens of minutes to display the same list of 320 files when mounted via gio mount and a second or so when mounted via mount -t cifs. The same timing difference is of course visible in any file manager. - + Hope this helps PS: several old/ancient bug reports exist for a similar issue and I deliberately copied the title from one of them (#259771) + + PS2: may or may not be relevant: The connection to the remote server was + made via VPN (Ubuntu stock SSTP)
** Description changed: Ubuntu 18.04 LTS here, fully updated (as of late Jan 2020). TEST #1: To establish a baseline/expected behavior, we first mount an SMB share via mount.cifs and time an ls command: $ sudo mount -t cifs -o username=pablo //myserver.example.com/share ~/mnt/share $ cd ~/mnt/share/some/dir $ time ls ... approx 320 files ... real 0m1,080s user 0m0,008s sys 0m0,005s $ sudo umount ~/mnt/share TEST #2 Now we do the same via gio mount: $ gio mount smb://myserver.example.com/share cd /run/user/1000/gvfs/smb-share\:server\=myserver.example.com\,share\=share/some/dir $ time ls ... same 320 files ... real 0m28,999s user 0m0,013s sys 0m0,032s Enumeration of files is about 29 times slower when mounted via gio mount than via mount -t cifs. TEST #3 Now for the real weird: while using the gio-mounted folder, we now time ls IN COMBINATION WITH SOMETHING ELSE (can be strace ls, ls|wc etc...): $ time ls | wc 321 323 9804 real 0m0,546s user 0m0,006s sys 0m0,004s Note that this is almost TWICE AS FAST than the "fast" mount of test #1 and about 53 times faster than "slow" test #2 ! The expectation is that Tests 1 and 2 should have similar timings, not differing by a factor of 30 or so. More disturbing, there is no good reason why tests 2 and 3 differ by an even bigger factor of 53: They use the same underlying infrastructure which test 3 proves is adequately fast. And yet, we get this slow down in test 2. As a final note, these benchmarks are a distilled version of the original real-life motivating scenario where a Java-based program would simply take tens of minutes to display the same list of 320 files when mounted via gio mount and a second or so when mounted via mount -t cifs. The same timing difference is of course visible in any file manager. Hope this helps PS: several old/ancient bug reports exist for a similar issue and I deliberately copied the title from one of them (#259771) - PS2: may or may not be relevant: The connection to the remote server was - made via VPN (Ubuntu stock SSTP) + PS2: may or may not be relevant: The remote server runs Windows 7 (yes, + I know...) and the connection was made via VPN (Ubuntu stock SSTP). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1862264 Title: Browsing smb share is painfully slow To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+bug/1862264/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
