[Bug 1862264] [NEW] Browsing smb share is painfully slow
Public bug reported: 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 ... real0m1,080s user0m0,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 ... real0m28,999s user0m0,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 3239804 real0m0,546s user0m0,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) ** Affects: ubuntu Importance: Undecided Status: New -- 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
[Bug 1862264] Re: Browsing smb share is painfully slow
** 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 3239804 + 321 3239804 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 3239804 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
[Bug 1862264] Re: Browsing smb share is painfully slow
** 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 3239804 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 remote server runs Windows 7 (yes, - I know...) and the connection was made via VPN (Ubuntu stock SSTP). + PS2: may or may not be relevant: The remote server is a VM running + Windows 7 (yes, I know...) and the connection was made via VPN (Ubuntu + stock SSTP). + + PS3: Another data point (server is now a Synolgy NAS, not a Win7 VM) + + $ gio mount smb://nas.example.com/share2 + + $ cd /run/user/1000/gvfs/smb- + share\:server\=nas.example.com\,share\=share2/another/path + + $ time ls + + ... 528 subdirs approximately ... + + real 0m45,075s + user 0m0,013s + sys 0m0,058s + + $ time ls | wc + 5281631 10893 + + real 0m0,911s + user 0m0,003s + sys 0m0,005s + + Factor is about 50. -- 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
[Bug 1862264] Re: Browsing smb share is painfully slow
** Package changed: ubuntu => gvfs (Ubuntu) -- 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/+source/gvfs/+bug/1862264/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1862264] Re: Browsing smb share is painfully slow
Looks like gio is part of glib, not gvfs, so changed the package accordingly. Also made clear in the title that gio vs mount is part of the issue. ** Package changed: gvfs (Ubuntu) => glib2.0 (Ubuntu) ** Summary changed: - Browsing smb share is painfully slow + Browsing smb share is painfully slow when mounted via "gio" (compared with "mount") -- 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 when mounted via "gio" (compared with "mount") To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/1862264/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1862264] Re: Browsing smb share is painfully slow when mounted via "gio" (compared with "mount")
Reported upstream as issue 2062 (https://gitlab.gnome.org/GNOME/glib/issues/2062) ** Bug watch added: gitlab.gnome.org/GNOME/glib/issues #2062 https://gitlab.gnome.org/GNOME/glib/issues/2062 ** Description changed: + Reported upstream as issue 2062 + (https://gitlab.gnome.org/GNOME/glib/issues/2062) + 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 3239804 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 remote server is a VM running Windows 7 (yes, I know...) and the connection was made via VPN (Ubuntu stock SSTP). PS3: Another data point (server is now a Synolgy NAS, not a Win7 VM) $ gio mount smb://nas.example.com/share2 $ cd /run/user/1000/gvfs/smb- share\:server\=nas.example.com\,share\=share2/another/path $ time ls ... 528 subdirs approximately ... real 0m45,075s user 0m0,013s sys 0m0,058s $ time ls | wc - 5281631 10893 + 5281631 10893 real 0m0,911s user 0m0,003s sys 0m0,005s Factor is about 50. -- 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 when mounted via "gio" (compared with "mount") To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/1862264/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
