S3 mount: mkdir takes too long despite VFS cache

What is the problem you are having with rclone?

On an S3 mount, mkdir takes more than 30 seconds, despite enabling the VFS cache for writes. Subsequent mkdir commands return immediately, but after a while, it goes back to taking more than 30 seconds to return.

I'm running rclone in Docker using the image rclone/rclone:1.65.2 with the following docker run options:

--device /dev/fuse
--cap-add SYS_ADMIN
--security-opt="apparmor=unconfined"

and volumes:

/path1:/data:shared
/path2:/cache:rw
/etc/passwd:/etc/passwd:ro
/etc/mime.types:/etc/mime.types:ro

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

rclone v1.65.2
- os/version: alpine 3.19.0 (64 bit)
- os/kernel: 5.10.0-28-cloud-amd64 (x86_64)
- os/type: linux
- os/arch: amd64
- go/version: go1.21.6
- go/linking: static
- go/tags: none

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

S3-compatible: Oracle Cloud Object Storage (OCI).

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

rclone mount oci:my-bucket /data/mydir \
  --vfs-cache-mode writes \
  --transfers 128 \
  --cache-dir /cache \
  --use-json-log

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

; empty config
### Double check the config for sensitive info before posting publicly
2024/02/28 23:24:18 NOTICE: Config file "/home/myuser/.rclone.conf" not found - using defaults

Environment variables:

TZ=Asia/Riyadh
RCLONE_CONFIG_OCI_TYPE=s3
RCLONE_CONFIG_OCI_PROVIDER=Other
RCLONE_CONFIG_OCI_ACCESS_KEY_ID=[REDACTED]
RCLONE_CONFIG_OCI_SECRET_ACCESS_KEY=[REDACTED]
RCLONE_CONFIG_OCI_ENDPOINT=https://[REDACTED].compat.objectstorage.me-jeddah-1.oraclecloud.com

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

{"level":"debug","msg":"Lookup: name=\"TEST1\"","object":"/","objectType":"*mount.Dir","source":"mount/dir.go:76","time":"2024-02-29T00:10:55.753618+03:00"}
{"level":"info","msg":"vfs cache: cleaned: objects 0 (was 0) in use 0, to upload 0, uploading 0, total size 0 (was 0)","source":"vfscache/cache.go:816","time":"2024-02-29T00:11:21.43011+03:00"}
{"level":"debug","msg":"\u003eLookup: node=\u003cnil\u003e, err=no such file or directory","object":"/","objectType":"*mount.Dir","source":"mount/dir.go:79","time":"2024-02-29T00:11:27.596044+03:00"}
{"level":"debug","msg":"Mkdir: name=\"TEST1\"","object":"/","objectType":"*mount.Dir","source":"mount/dir.go:161","time":"2024-02-29T00:11:27.596341+03:00"}
{"level":"debug","msg":"Added virtual directory entry vAddDir: \"TEST1\"","object":"","objectType":"string","source":"vfs/dir.go:439","time":"2024-02-29T00:11:27.596418+03:00"}
{"level":"debug","msg":"\u003eMkdir: node=TEST1/, err=\u003cnil\u003e","object":"/","objectType":"*mount.Dir","source":"mount/dir.go:168","time":"2024-02-29T00:11:27.596452+03:00"}
{"level":"debug","msg":"Attr: ","object":"TEST1/","objectType":"*mount.Dir","source":"mount/dir.go:33","time":"2024-02-29T00:11:27.596506+03:00"}
{"level":"debug","msg":"\u003eAttr: attr=valid=1s ino=0 size=0 mode=drwxr-xr-x, err=\u003cnil\u003e","object":"TEST1/","objectType":"*mount.Dir","source":"mount/dir.go:44","time":"2024-02-29T00:11:27.596578+03:00"}

welcome to the forum,

add -vv for debug output

Updated with -vv logs.

can you post a normal debug, no json.
full log, including the exact command and top lines.
and the exact time of the issue?

VFS is only a file cache, not a directory cache, so any directory operations are synchronous.

Adding to that, you don't seem to have any dir-cache-time specified, so it uses the default 5m and needs to re-read the complete directory listing after that, which may explain the occasional 30s delays while it processes the latest directory listing.

What are my options? This 30-second delay is harming my application.

Is there a way to skip/bypass the directory listing? The new directory is a UUID, so I'm not worried about a "directory already exists" type of problem.

Try to add:

--dir-cache-time 9999h --vfs-fast-fingerprint --vfs-refresh

More details about every flag in docs.

In short it will pre-warm cache after you start mount - keep dirs cache in memory valid for 9999h and use fast way to update it when needed.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.