- os/arch: linux/amd64
- go version: go1.13.8
to upgrade I only installed from website, got the error about fuser3 fixed with a symlink, and only added the --vfs-fast-fingerprint which was the mod I think my in-house team dev did at the time. But obviously something as well is missing. And the performance impact is huge.
Unfortunately the dev is not working with us anymore so I don't exaclty what was done, but i'm pretty sure it was something similar to --vfs-fast--fingerprint
I'm downloading to a zfs pool of nvme disks not used within OS. Usually between 2 to 6 nvme disks, so with a 10 gpbs NIC I'm trying to download files as quickly as possible to disk so all future reads are from cache but I don't want to do that in a blocking way.
With those settings shouldn't the entire file have been downloaded even if I read just 67 MB? or at least 256MB ?
I think this is part of the issue. I was expecting rclone to download the entire files at the first read, regardless of how much has been read, and then move on. If this is not happening then yes a huge amount of open files with empty cache will cause issues
Now I have 2 servers one with v1.55 and v1.62 and I will see if there is performance differences again.
This also explain the other issue in the other topic about high writes/bandwidth use even after no new files are open... they'd only be fully downloaded if read to the end
So far no difference in performance between 1.55 and 1.62 so I believe the issue yesterday is probably related to the rclone settings that is not having the expected behavior. Too many open files + empty cache + not saving data to disk so lots of wasted bandwidth
But error 500 messages I get with 1.55 and r2 doesn't appear in 1.62
I could do this with a patch to the VFS which when you opened a file which wasn't fully cached would start a process off to open the file and read it onto the disk completely regardless of whether the client had the file open or not.
That would be reasonably straight forward and would mean that the client didn't have to wait for the file to be downlaoded in its entirity. Rclone could also do the equivalent of --multi-thread-streams to download multiple parts of the file at once.
I think this would be good. You saw in that other thread that there is a lot of use cases where we need more aggressive disk writing.
I still think that all the vfs read flags are somewhat confusing, and difficult to understand how they interact with each other.
On sunday, I had all my servers running with 1.62 to randomly reboot because the php threads was getting stuck waiting for i/o for over 120 seconds.
I was unable to debug further because when I enabled debug logs the issue went away. This never happened before in ages with 1.55 so I don't know if this was because of my remote ( cloudflare r2 ) or the new rclone version.
The servers were getting the php threads stuck even with minimal writes/downloads/cpu usage.
Should I worry about 1.62 being meant for fuser3 which is not available on ubuntu 18.04 ?