Rclone mount upload stalls

Help and Support
1

What is the problem you are having with rclone?

I am trying to upload a large (~130GB) amount of large (~1GB) files to my remote by copying into an rclone mount. It works well, but after some time it stalls. Unmounting and restarting rclone mount seems to resume. Log stats show stalled (0/s) as does my network activity (and remote side stops growing when I look at it directly).

What is your rclone version (output from rclone version)

rclone v1.54.1

  • os/arch: linux/amd64
  • go version: go1.15.8

Which OS you are using and how many bits (eg Windows 7, 64 bit)

Debian stable 64bit

Which cloud storage system are you using? (eg Google Drive)

crypt over union over two SFTP

The command you were trying to run (eg rclone copy /tmp remote:tmp)

rclone -vv --syslog \
         mount --daemon \
         --stats 1m \
         --dir-cache-time 48h \
         --vfs-read-chunk-size 32M \
         --vfs-read-chunk-size-limit 2G \
         --buffer-size 512M  \
         --vfs-cache-mode full \
         --daemon-timeout 5m \
         --cache-dir /home/singpolyma/.cache/trusted-offsite-crypt \
         trusted-offsite-crypt: /home/singpolyma/trusted-offsite-crypt

The rclone config contents with secrets removed.

[trusted-offsite-crypt]
type = crypt
remote = trusted-offsite:crypt/
filename_encryption = standard
directory_name_encryption = true
password = ...
password2 = ...

[ossguy]
type = sftp
host = ...
port = 333
use_insecure_cipher = false
known_hosts_file = /home/singpolyma/.ssh/known_hosts
md5sum_command = md5sum
sha1sum_command = sha1sum

[weber-ds]
type = sftp
host = ...
use_insecure_cipher = true
md5sum_command = md5sum
sha1sum_command = sha1sum

[trusted-offsite]
type = union
upstreams = ossguy:/media/singpolyma/singpolyma/ weber-ds:homes/singpolyma/
action_policy = all
create_policy = all

A log from the command with the -vv flag

Full log at, below is useful snippet.
http://0x0.st/-Z8_.txt

Mar  9 14:26:08 singpolyma-beefy rclone[13786]: vfs cache: cleaned: objects 243 (was 243) in use 243, to upload 239, uploading 4, total size 114.854G (was 114.854G)
...snip...
Mar  9 14:21:08 singpolyma-beefy rclone[13786]: vfs cache RemoveNotInUse (maxAge=3600000000000, emptyOnly=false): item bup/objects/pack/pack-cd8b6edafeee595694dd17d39f51676e23e88a5c.pack not removed, freed 0 bytes
Mar  9 14:21:08 singpolyma-beefy rclone[13786]: vfs cache RemoveNotInUse (maxAge=3600000000000, emptyOnly=false): item bup/objects/pack/pack-d3c66289b3bdf5e4225cc2f24f20371fee51fc6a.idx not removed, freed 0 bytes
Mar  9 14:21:08 singpolyma-beefy rclone[13786]: vfs cache RemoveNotInUse (maxAge=3600000000000, emptyOnly=false): item bup/objects/pack/pack-d94aa96abb20f7b52ba31a896474ee0eabb7f0bd.idx not removed, freed 0 bytes
Mar  9 14:21:08 singpolyma-beefy rclone[13786]: vfs cache RemoveNotInUse (maxAge=3600000000000, emptyOnly=false): item bup/objects/pack/pack-639fdd17935d07fcb606eb7e51db820b923bf85a.idx not removed, freed 0 bytes
Mar  9 14:21:08 singpolyma-beefy rclone[13786]: vfs cache RemoveNotInUse (maxAge=3600000000000, emptyOnly=false): item bup/objects/pack/pack-babf7aef1a29e5a09daad97c48aa821b071b3fbd.pack not removed, freed 0 bytes
Mar  9 14:21:08 singpolyma-beefy rclone[13786]: vfs cache RemoveNotInUse (maxAge=3600000000000, emptyOnly=false): item bup/objects/pack/pack-f6972f33340bf94659444b2992e8d56cb75de59d.pack not removed, freed 0 bytes
Mar  9 14:21:08 singpolyma-beefy rclone[13786]: vfs cache RemoveNotInUse (maxAge=3600000000000, emptyOnly=false): item bup/objects/tmpbhQaF1.pack not removed, freed 0 bytes
Mar  9 14:21:08 singpolyma-beefy rclone[13786]: vfs cache RemoveNotInUse (maxAge=3600000000000, emptyOnly=false): item bup/objects/pack/pack-9d16122277410910b8d3ea3a9121bf61f02323d5.pack not removed, freed 0 bytes
Mar  9 14:21:08 singpolyma-beefy rclone[13786]: vfs cache: cleaned: objects 243 (was 243) in use 243, to upload 239, uploading 4, total size 114.854G (was 114.854G)
Mar  9 14:21:46 singpolyma-beefy rclone[13786]: #012Transferred:   #011    7.141G / 9.338 GBytes, 76%, 1.258 MBytes/s, ETA 29m49s#012Transferred:           13 / 17, 76%#012Elapsed time:    1h37m2.8s#012Transferring:#012 * bup/objects/pack/pack-…f2b190c9a6752be3a.pack:  7% /953.683M, 0/s, 0s#012 * bup/objects/pack/pack-…498e41e21d76e0d44.pack: 94%
 /953.705M, 0/s, 0s#012 * bup/objects/pack/pack-…ae131ec409fcfa502.pack: 30% /950.141M, 0/s, 0s#012 * bup/objects/pack/pack-…b925ab0a1e4d06fc3.pack: 31% /953.677M, 0/s, 0s#012
2

hello and welcome to the forum,

is there a reason not to use rclone copy which is more reliable and efficient?

3

rclone copy would require that I have the data locally somewhere. In my case, I'm producing the data directly into the mountpoint (such as by running my backup program pointed at the mointpoint, etc). Of course, this results in it being saved locally in the cache directory, so maybe I could unmount, rclone copy from the cache directory by hand, then mount again, though that feels like a workaround at best.

The other reason I'm using rclone mount is that I want the copy-in-background resume-later behaviour that it has. If the upload doesn't finish now and I need to turn my system off, I don't want to really have to think about it and just have the upload resumed when I next book, which from my testing rclone mount handles quite well.

4

The first reason is covered by producer | rclone rcat remote:

5

This looks like the sftp connections have stalled...

This is the kind of thing --timeout is supposed to pick up however the SFTP backend doesn't take notice of that flag because it opens low level TCP connections.

I have an idea on how to fix this...

Will have a play tomorrow

1 Like
6

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.