for many smaller files, juicefs is slower than rclone

[lddlww]

you can firstly check and download fuse_test repo which has about 7459 directories and 36420 files:

git clone https://github.com/lddlww/fuse_test.git

os version：ubuntu 24.04 LTS

rclone mount parameter:

rclone mount myminio:bucket1 /data/rclone --vfs-cache-mode full --dir-cache-time=72h  --vfs-cache-max-age 24h --vfs-cache-max-size 100G  --transfers 32 --checkers 64 --write-back-cache --attr-timeout 1h --no-checksum  --no-modtime  --allow-other --daemon

juicefs mount parameter:

juicefs mount $METAURL /data/juicefs -d --writeback

juicefs metadatabase is single redis

copy test:

1. time cp -a  fuse_test/go /data/rclone
real 58s

2. time cp -a  fuse_test/go /data/juicefs
real 2m52s

the test above shows that juicefs is slower than rclone when handling many small files with the same minio storage. Is this expected?

thanks in advantage

[jiefenghuang]

There are many parameters you can tune—such as attr-cache, entry-cache, and so on—similar to the flags you use with rclone. For specific usage, please refer to the official documentation or the command‑line flag descriptions.

I suggest that when running your tests, you can check the cmd/stats output and then fine‑tune the parameters based on that.

[lddlww]

i set some parameters with juicefs mount, but there is almost no improvement

juicefs mount $METAURL /data/juicefs -d --writeback --max-stage-write 20 --attr-cache 100 --entry-cache 100 --dir-entry-cache 10 --verify-cache-checksum none --upload-delay 1000 --open-cache 100

seems fuse and blockcache throughput is unstable

[jiefenghuang]

What metadata engine are you using? Also, check the disk status during execution, since many small files are being written—make sure the bottleneck isn’t disk I/O.

[lddlww]

redis version is 7.0.15, i checked it and found there is no bottleneck for disk i/o as throughput and iops is very lower

[jiefenghuang]

The bottleneck seams to be the metadata operations. 1000 / 0.32 is approximately your FUSE operation throughput. The cp command is single-threaded, and each file requires about 7–8 metadata operations. The total latency is around 0.33 * 8 = 2.64 ms per file, so you’re copying roughly 1000 / 2.64 ≈ 378 small files per second. As of now, requests like setattr, write, and flush are unavoidable.

If you execute multiple cp operations concurrently, you should observe an increase in metadata latency.

[lddlww]

you are right，thanks for reply