Hey guys, I’m not really sure if I comprehend the use of --dir-cache-time and --cache-info-age, so I was wondering which would be the best values for these settings when I have a permanent media library that receives some files from outside the mount.
A while ago I used the default settings and the mount would respond pretty quickly, but newer stuff being updated from outside the cache wouldn’t show up.
@Animosity022’s settings would be a good starting point. I started with his and the rclone cache worked really nicely. Although I had changed a few of them to better fit the speed of the server I was on.
You may want to look at the wiki https://rclone.org/cache/#mount-and-dir-cache-time for more info on --dir-cache-time. The page is very helpful in finding out what each cache option does. Although with the recent beta feature, cache is becoming obsolete. Now the VFS cache option can work just as fast with the bonus of it not using double the disk space for moving files to the mount (if you have it set to keep files temporarily in the tmp folder before uploading).
You mean these settings? “Guide to replaceing plexdrive/unionfs with rclone cache”
I was worried that the settings below would be generate the issue I related, where the things on the mounted drive are not up to date with recent uploads from outside the mount.
–dir-cache-time=160h
–cache-chunk-size=10M
–cache-info-age=168h \
Because the docs for “–cache-info-age=” say that this value can be big as long as all the operations are made through the cache.
I’m not sure if this means through the mount point or ponting towards the cache remote in the rclone copy/move command…
The cache won’t delete files from your GDrive. It will put paths of the files into a database and read from that database based on the dir-cache-time and cache-info-age. The longer they are, the longer a folder will show up in your cache even if it get’s deleted directly on GDrive, if that makes sense.
Also if you aren’t using crypt then for your cache setup, the remote will be gdrive instead of gmedia.
I can link you my old ones that I used before switching to VFS.
rclone mount gmedia: /folder/gmedia \
--dir-cache-time=160h \
--cache-db-path=/ssdfolder/rclone \
--cache-chunk-path /folder/rclone \
--cache-chunk-size=50M \
--cache-info-age=168h \
--cache-workers=5 \
--cache-tmp-upload-path /home/user/rclone-up \
--cache-tmp-wait-time 60m \
--buffer-size 0M \
--umask 002 \
--rc \
--log-level INFO \
--log-file=/folder/rclone.log
And the rclone.conf is setup the same as his on the page you linked.
I’ll try it out. Thanks!
And where can I read more about that VFS?
The VFS flags are documents as part of the mount command
The VFS layer itself is a layer which converts the raw primitives the rclone backends provide into a file system like layer. There isn’t a perfect match, hence the --vfs-* options for controlling it.
So should I get on board the vfs method and abandon cache mount? Or is it still too early for that?
There are cons to the VFS layer. I had a few just yesterday. A large transfer of 80GB through radarr failed so it ended up having to redo it (which took 2 hours per try). I also notice a much slower speed through writing since it’s only using read chunk sizes not write chunk sizes, so it can’t upload multiple chunks at once I guess. Changing the buffer size doesn’t do anything either. This is the config I’m using though for VFS https://forum.rclone.org/t/new-feature-vfs-read-chunk-size/5683/84
An upside to using VFS though is a faster startup time for streaming files, no waiting for 40 seconds for the cache to build up since there isn’t one. And also too with these options, no doubling of needed HDD space for the rclone tmp upload folder since it uploads directly now (although that means no retries in rclone)
Sounds very promising for mounts where reading is the priority! I’ll give it a shot.
And what happens if I upload stuff from outside the mount? Is there any directory update issue?