2h of reading the manual later I think if the above command be run with --rc (flag enabling remote control) then running rclone rc vfs/refresh -v --fast-list recursive=true will precache all directories making the traversals much faster. Still need to test it though and find a way to integrate it with systemd
thanks a lot, I see that it doesn't use the --fast-list flag for precaching and also added _async=true. This may be a separate question, but is there anything inappropriate with using fast-list (also Google Drive)?
for some reason systemd fails when running the service with this line ExecStartPost = rclone rc vfs/refresh recursive=true _async=true --rc-addr :5572 --rc-user user --rc-pass password The unit rclone-gdrive-mount.service has entered the 'failed' state with result 'exit-code'.
not sure why, it is the same as in the example above
I assume RestartSec was needed to wait longer for the async job to maybe like wait for a response from somewhere or maybe KillMode was set to kill it at some point.
Not sure; hopefully, it will speed up listing of the directories now.
that makes sense, it was still worth trying, because it showed that the rclone rc vfs/refresh timed out after 5 minutes rclone documentation mentioned that's a default (Documentation) and can be overwritten with the --timeout flag added to the rclone rc vfs/refresh command
Hmm, I'm not sure if it may be google just throttling my account, but with over 5TB of data stored it can take hours to refresh. Is there really no way to cache this to disk? Isn't that what windows' Google Drive desktop client does by default?
I think you are talking about two different things here.
vfs/refresh is just for metadata so directory and file structure.
Thats impacted by dir-cache-time and on a mount since Google Drive is a polling remote, you can have that value high.
I use that to precache my directory / file structure in memory so when my machine boots and starts the rclone mount, the directory listing is fast.
So when I run a directory listing, it comes back instantly.
felix@gemini:/GD$ time ls -alR | wc -l
The dir cache is lost when you reboot or restart the mount and the 'priming' of the mount needs to be done which is why I have it as part of my startup command to just make things faster for browsing. The time is takes is not dependent on the size but more so on the number of directories/files you have and how it's laid out.
Dir-cache-time has nothing directly to do with file based caching on disk with vfs-cache-mode full. That's for storing the actual data on the files and when you mount something with rclone, it only grabs when you ask it to grab. So if you read a file, it gets what you/the application has requested. The vfs-cache-mode data is persistent and sticks around on reboots.