A tip that saved me real time (and transaction cost) on large object-store remotes — S3, B2, GCS, etc.
By default rclone lists a bucket directory-by-directory: roughly one API call per prefix. On a remote with thousands of prefixes that's thousands of List calls — slow, and on B2/S3 each one is a billable class-B/list transaction.
--fast-list flips this to a single recursive listing: rclone pulls the object list in as few calls as the backend allows, builds the tree in memory, then works from that. On a bucket I rclone size nightly this dropped the run from ~40s and well over a thousand list transactions to a few seconds and a handful of calls.
When it helps
- Bucket / object-store backends (s3, b2, gcs, swift, azureblob) that have many directories.
- Operations that need the whole tree anyway:
sync,size,dedupe,check,lsf -R.
When it hurts (or does nothing)
- Backends that can't do a cheap recursive list — rclone effectively ignores it and you see no speedup.
- Huge flat buckets on a small box: it holds the entire listing in RAM. Millions of objects = real memory; watch RSS before you bake it into a cron job.
Gotchas
- It changes listing, not transfer — pair it with
--checkers/--transferstuning if throughput (not enumeration) is your bottleneck. - To make it permanent without editing every command, set
RCLONE_FAST_LIST=truein the environment — rclone maps every global flag to anRCLONE_*env var, which keeps cron/systemd units clean.
Quick before/after to measure the win on your own remote — run each with -vv and compare the transaction/time lines in the log:
rclone size remote:bucket -vv
rclone size remote:bucket --fast-list -vv