I modeled my mount line based on your github script, no major tweaks I can think of off hand. I'm using vfs full, with a 50GB local cache, I thought that would allow incremental reads. Where I'm going with this- could I have a setting in the mount parameters that would cause a full pull down on any read attempt (i.e. preventing the partial read from happening)?
In general, the mount only ever delivers what it was asked for with the only case I'm aware of adjusting that to a much larger amount is by using --vfs-read-ahead to a huge value and making it download more than I needed.
I don't use that option personally.
Ok thanks! I'm not using read ahead either, my connection is good enough that I don't think there's any benefit for me getting a read ahead either. I'll keep experimenting with it. The only other thing I can think of it that these are copies of things already in my library. I had hoped Plex would just associate them to the existing entries like it usually does with no fuss, but I wonder now if it's doing some extra check to verify they are in fact the same item.
If they are the same item(same size, same modtime, but different path), it wouldn't analyze but just adjust the path.
The plex logs show this info.
With VFS full caching, does any data, apart from the file structure, get cached to the RAM?
Does this adversely affect SSD life or decrease I/O throughput?
I've found VFS full to be faster, at the expense of more data usage but I'm worried about SSD life in the long-term and reduction in I/O throughput. With RAM caching, these weren't an issue.
Files still use --buffer-size so you get that per file opened.
I'm not a SSD expert so I really could not weigh in much other than I'd assume more use does but I've had the same SSD in my Linux box for a few years and haven't noticed anything yet.
It's also no different from my Macs which have SSDs and have lasted for many years.
Is there any way to limit upload bandwidth with VFS writes?
After importing from Sonarr, I think (by default) transfers are 4 at a time. That must really saturate the connection and cause slowdowns.
If I specify --transfers=2, won't it quite possibly affect Plex refreshes, since it tends to do them 3 at a time??
In a mount or a script? Transfers does nothing on a mount.
Mount. Any other way to avoid saturation?
Also how many files are uploaded at once with VFS writes?
Not sure I'm following as I don't use vfs-writes in my settings anywhere.
It's just a question. With VFS full, how many transfers?
A mount doesn't use transfers as it serves as many files as it's asked for.
I don't upload on my mount directly as I use rclone move directly to the remote.
I think with the vfs rewrite or somewhere around that period, mount has indeed started using the --transfers flag for controlling the number of simultaneous uploads. Reads/Downloads are still unlimited.
@ncw can confirm this.
Can we start a new thread as it's off topic here. I was alluding to that and figured I'd be more direct.
Sure, no problem, sorry for taking it off-topic. Just wanted to clarify that in case someone reads this in the future.
How does the max-size and max-age logic work?
Say, after max-age is reached, does the cache clear even though the cache is well within max-size?
I guess you actually mean the vfs parameters and not the filtering parameters you listed max-age and max-size?
It only empties stuff from cache when max size is reached. Once max size is reached, it does items not being used and the oldest items in the cache first.
Since Nick fixed a bug with --no-modtime earlier, I was wondering if there is any benefit to using that flag with my read-only, no-poll Plex mount? With the flag, I noticed that files show the mod date/time of the folder they're in instead of their own. Does that have any negative effect on a Plex scan as far as "date added", for example?
Apologies if I've asked this question before 
It's been a few versions since I tested this with Plex but my understanding is that Plex validates size, date/time on the file to see if anything changed. If you made a change on the mount and changed the modtimes, it would recsan the content is what I believe would happen.
If you were starting fresh, there's no reason I can think of to stop you from doing that with the exception of when the file moves from local to remote.
My local (Linux) would have the right modtime on it and once uploaded it would change so that would not work for my setup. I'm not sure how Windows handles that though.
1 Like
In Windows, mod time stays the same after the upload. So, it sounds like using --no-modtime is not a good idea for our mounts. I don't want to risk Plex having to re-scan everything 
Thanks for the quick reply!