[Solved] Very Slow Read Speed on Rclone Mount

Help and Support
1

I am experiencing very slow read speeds on an rclone mount using the following systemd process to mount files from a google team drive:
[Service]
Type=notify
Environment=RCLONE_CONFIG=/opt/rclone/rclone.conf
KillMode=none
RestartSec=5
ExecStart=/usr/bin/rclone mount gcrypt: /GD
--allow-other
--allow-other
--attr-timeout 1000h
--buffer-size 1G
--dir-cache-time 1000h
--log-level DEBUG
--log-file /logs/rclone.log
--poll-interval 15s
--timeout 1h
--read-only
ExecStop=/bin/fusermount -uz /GD
Restart=on-failure
User={myusername}
Group={myusername}

[Install]
WantedBy=multi-user.target

My speeds when reading directly from my mount are approximately 333 times slower than using an rclone copy command (300 kilobytes per second vs 100+ megabytes per second).

I am using
`rclone v1.50.2

  • os/arch: linux/amd64
  • go version: go1.13.4`

Here is the relevant portion of my rclone log file.

I am running the latest version of Arch Linux.

1 Like
2

I can't see anything obviously wrong in your log.

How are you measuring the speed?

3

Method 1 (Fast):

rclone copy gcrypt:archlinux.iso /home/username/test1.iso --progress

Transferred: 627M / 627 MBytes, 100%, 94.145 MBytes/s, ETA 0s
Errors: 0
Checks: 0 / 0, -
Transferred: 1 / 1, 100%
Elapsed time: 6.6s

Method 2:

rclone copy /GD/archlinux.iso /home/username/test2.iso --stats 5s

Transferred: 2.996M / 627 MBytes, 0%, 306.791 kBytes/s, ETA 34m42s
Errors: 0
Checks: 0 / 0, -
Transferred: 0 / 1, 0%
Elapsed time: 10s
Transferring:

(Note that the transfer speed does not increase).

4

Which Linux Kernel are you running? Distro? There is an issue confirmed by several users with kernel 5.4 resulting in slow speed on mounts

5

System Information

Kernel: 5.4.2-arch1-1
x86_64 bits: 64
Desktop: Gnome 3.34.1
Distro: Arch Linux
fusermount version: 2.9.9

6

It is very likely you experience the same issue as described here:

If possible please try with a 5.3.x kernel

7

Running with a 5.3.x kernel fixes the issue.

8

Ok one more data point to confirm the issue, thx.

@ncw i can run some tests next week , or do you have anything on this yet?

9

I just had a look through the diffs from 5.3 to 5.4. The fuse layer was heavily re-worked with 69 patches and this diffstat

 fs/fuse/Kconfig     |   11 ++
 fs/fuse/Makefile    |    2 +
 fs/fuse/cuse.c      |  101 ++++++-------
 fs/fuse/dev.c       |  656 +++++++++++++++++++++++++++++++++++++-----------------------------------------------
 fs/fuse/dir.c       |  299 +++++++++++++++++++++++----------------
 fs/fuse/file.c      | 1241 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-------------------------------------------------------------------------
 fs/fuse/fuse_i.h    |  361 +++++++++++++++++++++++------------------------
 fs/fuse/inode.c     |  561 +++++++++++++++++++++++++++++++++++++++++-------------------------------
 fs/fuse/readdir.c   |   72 ++++++----
 fs/fuse/virtio_fs.c | 1252 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 fs/fuse/xattr.c     |   76 +++++-----
 11 files changed, 3035 insertions(+), 1597 deletions(-)

So it wouldn't surprise me if there was a regression there.

Looking at the changelog from 5.4 onwards I see some fixes for regressions introduced by those patches.

Is anyone brave enough to try v5.5-rc1 which should have those fixes?

10

Uhm I just use 5.5.0-1 on fedora with XFCE spin and Thunar and it's very sluggish. Is there any work around or temp fix other than kernel downgrade?

11

The rclone beta has a workaround for this - give that a go