Displaying root in Google Drive mount taking ages

Help and Support
1

What is the problem you are having with rclone?

I have a mount to Google Drive. When I double click to open the virtual disk it takes ages to show the file list. If I manually input the path to a subfolder (one with many, many more files than the root folder), it opens it almost instantly.

Run the command 'rclone version' and share the full output of the command.

rclone v1.68.2
- os/version: linuxmint 22 (64 bit)
- os/kernel: 6.8.0-51-generic (x86_64)
- os/type: linux
- os/arch: amd64
- go/version: go1.23.3
- go/linking: static
- go/tags: none

Which cloud storage system are you using? (eg Google Drive)

Google Drive

The command you were trying to run (eg rclone copy /tmp remote:tmp)

It's not a command per se or, if it is, I don't know what command it would be, since I am not using it through command line. I simply try to open the root folder on desktop. And it takes ages.

Please run 'rclone config redacted' and share the full output. If you get command not found, please make sure to update rclone.

[gdrive]
type = drive
client_id = XXX
client_secret = XXX
scope = drive
token = XXX
team_drive =

A log from the command that you were trying to run with the -vv flag

https://pastebin.com/BhJMKDNN
2

I might add that accessing folders or files when using the direct path is almost istantaneous too.

Edit: also, the initial "/generic/path: Removing directory" entries referred to a long list of folders and subfolders which I have anonimyzed.

3

No ideas? I can't understand what logic might be behind this behavior.

4

Is something missing from my report?

5

There's a bunch of stuff that's redacted I think you said so makes it tough as I can't tell what's going on in the log file tbh.

Add

  --vfs-refresh                            Refreshes the directory cache recursively in the background on start

And that caches things on startup.

What is ages? Minutes?Hours? Log file seems to be seconds.

6

It's just file name, though. The structure of "what's happening" is all there.

This thing is not limited to after startup. It's recurring throughout the time the machine is on (which, save for the occasional reboot, is 24/7). I'll explain better below.

Ages is 50 seconds (it feels like that when you are working on a relatively modern PC, doesn't it?). I logged on now, the machine has been up for days.
I double click on the mounted disk and it took 50 seconds to display the root contents.

If I close the window and open again, it opens instantly. And that's understandable, it has cached that entry.

What I don't understand is that if I reopen in an hour, or two hours (never timed it, I think it's less than an hour, though), it takes again a long time to display.

If, with the window open and loading (before it displays root's content), I modify the path in the address bar and point to a folder that has far more folders and files than root, it's displayed pretty much instantly, a second at most.

Edit: could it be "--vfs-cache-max-age 30m", maybe?

7

Trying to correlate and parse through a log with mismatching/removed names is harder than a normal log. It just is for me so that's my reality.

I've never used a GUI on Linux so I wouldn't fathom to guess what it's doing or possibly opening up or trying to generate. The debug log with the timestamps matched up would give a hint.

That's how long files are cached in the cache area before removed from local cache. Depending on what the 'double click' is doing maybe, but that would mean it's downloading information on the files located in there and doing 'something. Debug log would show this.

If it just listing the structure, that's covered by "--dir-cache-time" "5000h" and refresh loads that up during startup.

A log file along with the timestamps of your first click and the window painting would be what I would look at.

8

The time stamps are there in the log and the log covers just me starting the service and opening the root window as soon as it's mounted. Then I stop the service. If you scroll down in the log I put notes about that. It's barely more than a minute all summed.

So there is basically no activity on the mounted drive before I open root folder and when content is displayed I stop the service.

If I browse the log I see lots of things repeating in structure of "what's happening", the problem is that I don't know how to interpret them.

9

You'd want to add that.

If you are 'clicking' on the folder or whatever that is and it's iterating through every folder and file, that would take some time on something not cached which is why I suggested to add vfs-refresh to cache the directory/file structure on the mount.

You can see a lot of file open in your log, which means 'something' is opening files and reading them.

2025/01/07 16:10:42 DEBUG : /: Lookup: name=".Trash"
2025/01/07 16:10:42 DEBUG : /: >Lookup: node=<nil>, err=no such file or directory

***** AND THEN THERE'S A BUNCH OF THESE. I KEPT ONLY THE FOLLOWING ENTRY BUT IT'S REPEATED FOR MANY SUBDIRECTORIES *****

2025/01/07 16:11:08 DEBUG : gA/#ABC/: Lookup: name="Antantes"
2025/01/07 16:11:08 DEBUG : gA/#ABC/: >Lookup: node=gA/#ABC/Antantes/, err=<nil>
2025/01/07 16:11:08 DEBUG : gA/#ABC/Antantes/: Attr: 
2025/01/07 16:11:08 DEBUG : gA/#ABC/Antantes/: >Attr: attr=valid=1s ino=0 size=0 mode=drwxrwxr-x, err=<nil>
2025/01/07 16:11:08 DEBUG : : Statfs: 
2025/01/07 16:11:08 DEBUG : : >Statfs: stat={Blocks:59055800320 Bfree:15943861964 Bavail:15943861964 Files:1000000000 Ffree:1000000000 Bsize:4096 Namelen:255 Frsize:4096}, err=<nil>
2025/01/07 16:11:08 DEBUG : : Statfs: 
2025/01/07 16:11:08 DEBUG : : >Statfs: stat={Blocks:59055800320 Bfree:15943861964 Bavail:15943861964 Files:1000000000 Ffree:1000000000 Bsize:4096 Namelen:255 Frsize:4096}, err=<nil>

***** AND HERE I HAVE STOPPED THE SERVICE AFTER THE CONTENT OF ROOT HAVE BEEN DISPLAYED *****

2025/01/07 16:11:25 DEBUG : /home/ashlar/gdrive: Unmounted externally. Just exit now.

Having a full log here would allow me to figure out how many directories it might be parsing thorugh and validate it's listing out everything.

Test with the flag I suggested a bunch of posts back, run a debug log, validate again.

10

I can do that but... am I wrong in understanding that that option works when the service is started?

As I stated, the machine is on 24/7, so the service starts every once in a while. Probably less than once a week. If I understand correctly, that wouldn't help much.

11

As you had stated, you started the mount, shared that log and have the problem.

I asked to set the flag and share a new log so it’s up to you as I can’t see your machine from here.

12

Yeah, no, I'm sorry... I simply wanted to clarify the usage pattern for the machine.

Since the service is started so rarely, I was afraid that that option would have had limited impact...

BUT

I've isolated the problem to the files saved in root. Not the folders, folders are fine and are now displayed pretty much instantly (38 folders are not much to just display).

I moved all the files (75 of them) to a specific folder and now, when I open that, it makes me wait the long wait. If/when I have time I will try to isolate by file type and report back here, just so you know what might be the cause, in case future users report something similar.

Thanks for the help!

13

Ok, apparently I have found the culprit.

It's .ady files, which are audio calibration files from Audyssey calibration program. They are several MB in size and they are basically text files... probably for "reasons" Linux tries to "read them" somehow and tthat takes time.

I should probably investigate with Linux Mint's community... I'll just need to find the time to do so.