VFS Mount Freezes

My current mount command:

"/home/darthshadow/rclone/bin/rclone" mount GDrive:Media /home/darthshadow/GMedia \
   --allow-other \
   --allow-non-empty \
   --dir-cache-time=720h \
   --drive-chunk-size=128M \
   --vfs-read-chunk-size=128M \
   --vfs-read-chunk-size-limit=off \
   --vfs-cache-mode=writes \
   --vfs-cache-max-age=1h \
   --vfs-cache-poll-interval=10s \
   --cache-dir=/home/darthshadow/rclone/ \
   --buffer-size=512M \
   --attr-timeout=1s \
   --umask=002 \
   --log-file=/home/darthshadow/rclone/rclone.log \
   --log-level=INFO \
   --stats=1m \
   --stats-log-level=NOTICE \

All the writes are done via the mount. Occasionally I have observed that the mount simply freezes for a particular directory or file. Doing anything in that directory also freezes, even a simple ls.

I have not been able to reproduce this with any consistency. Sometimes it happens immediately and sometimes after a few days. I have tried putting debug logs but since I can’t reproduce it manually, the logs are always rotated out by the time I notice this again.

Anything that looks wrong in the command or that may help in debugging this issue?

I’d change the log level to DEBUG and capture some logs when the issue happens.

That will be my last resort since the amount will simply be too much if it doesn’t occur within a few hours or so.

That means that the mount is stuck in the kernel. Specifically it means the kernel has asked rclone mount via FUSE to do something and rclone hasn’t responded yet.

A log file would be super helpful.

Ok, I will enable debug logging and turn off any log rotation so they don’t get rotated out. Hopefully it appears sooner rather than later to avoid the rather large log file that will be the result otherwise.

1 Like

Thanks to @darthShadow’s log and a bit of discussion I’ve managed to reproduce this


I haven’t figured out what is going on yet (it is too later here!) but I will!


Excellent. Hope this gets resolved soon.

I haven’t touched the --poll-interval flag in my config and have let it remain at the default 1m. What I have reduced the value for is the --vfs-cache-poll-interval. Is there any relation between these two parameters?

Increasing that will decrease the chance of the deadlock happening, but it will mean that the changes from drive don’t show up as quickly.

No - the --vfs-cache-poll-interval is how often rclone goes around looking for stuff to evict from the VFS on disk cache.

I don’t modify my drive other than through rclone, so do you think there would be any disadvantage in increasing it to a much higher value like 15m or even 30m to mostly avoid any chance of a deadlock, till the issue is fixed?

If you aren’t writing to your GDrive from another location, you could set it really high. For me, I’m all self contained on a single machine so that value could be set super high and I wouldn’t see an issue.

That would help.

However I’ve made a potential fix here for you to try:

https://beta.rclone.org/branch/v1.45-021-g5cc92ab0-fix-2811-deadlock-beta/ (uploaded in 15-30 mins)