To be honest, I’m not a big fan of the vfs-cache. I know it has to work around some limitations of FUSE, which makes it seem slow and buggy under some workloads.
For my uploads, I’m using triggered uploads when possible (when
taskX is done call
rclone move /download/taskX gdrive:upload) or something like
overlayfs and upload regularly.
Choosing the right settings for vfs-cache is heavily dependent on the programs used and device constraints like disk space.
The last time I used vfs-cache, most extracting tools needed
--vfs-cache-mode >= writes, which has the drawback to write the whole file to a local folder before uploading.
If you can use
--vfs-cache-mode off without errors, the disk space would not be an issue anymore.
Implementing a cache mode between
writes is an option, but this combines the weaknesses of both modes into a new one.
A program which is unable to operate on mode
off now will probably fail on the new mode also, as the flexibility of mode
writes give will vanish at some time while the file is opened and the operation can fail as before.
I don’t see the benefit of implementing a new mode and it would increase the complexity of the VFS layer even more.
We should instead improve the usability for mode
off for failing programs if possible.
@neik If you have a specific tool that fails with cache-mode
off you can post a debug log of your rclone mount and when possible two
One log of the failing tool (
strace -f -e file,read,write -o strace_rclone.log unrar x flie.rar) and one log for the same command on a local filesystem (
cd /tmp; strace -f -e file,read,write -o strace_local.log unrar x /mnt/rclone/flie.rar).
Maybe we can then find a solution.