Frequent Asked Questions

How is the performance of JuiceFS?

JuiceFS is a distributed file system, all the metadata and data must be fetched using network, it will be slower (higher latency) than local filesystem in general. The latency of metedata is determined by 1 (reading) or 2 (writing) round trip(s) between client and metadata service (usually 1-3ms within same region). The latency of first byte is determined by the performance of underlying object storage (10-100ms). Thrughput of sequential read/write could be 50MB/s - 400MB/s, depends on network bandwidth and how the data could be compressed.

JuiceFS is built with multiple layers of caching (invalidated automatically), once the caching is warmed up, the latency and throughput of JuiceFS could be close to local filesystem (having the overhead of FUSE).

How can I speedup moving small files into JuiceFS?

You could mount JuiceFS with --writeback, which will write the small files into local disks first, then upload them to object storage in background, this could speedup coping many small files into JuiceFS.

When my update will be visible to others?

All the metadata updates are inmediately visible to all others. The new data written by write() will be buffered in kernel or client, visible to other processes on the same machine, not visible to other machines. Once flush(), datasync() or close() is called, the buffered data will be commited (upload to object storage and update metadata), will be visible to all others once the call returns.

Does JuiceFS support random read/write?

Yes, including those issued using mmap. Currently JuiceFS is optimized for sequential reading/writing.

How is the size of JuiceFS calculated?

The size of JuiceFS is the sum of size of all the objects, each file or directory has a minimum billable size of 4KB (same as the Azure Data Lake Store), we recommend storing data in larger files to save costs.

The realtime size of each directory (including all the files and directories in it) could be checked in the web console.

Could JuiceFS be used by online service?

Yes. JuiceFS is designed to be a high available service (replicated in multiple available zones), with targeted uptime SLA as 99.95% per month.

The availability of JuiceFS is also determined by the availability of underlying object storage, which is usually claimed to be high available, for actual SLA, please check the docs for the cloud you are using. For replicated JuiceFS, it will be still available even one of the underlying object storage go down.

Where is my existing files in object storage?

Existing files in the object storage are not accessible throught JuiceFS, you can import them into JuiceFS very quickly, check out the user guide for details.

How to upgrade JuiceFS clients?

Please run juicefs version --upgrade, checkout the Command Reference for more detail.

How to unmount JuiceFS?

Please checkout the Getting Started .

Which cloud and region is supported?

Currently, all regions from Amazon Web Service (AWS), Google Cloud Platform (GCP), Aliyun(阿里云), UCloud, QingCloud(青云), TencentCloud(腾讯云), KSYun(金山云) and NeteaseCloud(网易云) are supported (may not open for public). Any public cloud, which supports Linux instance and object storage, could be easily supported by JuiceFS. If a public cloud or a region is not listed in web console, please contact us.

Is JuiceFS ready for production?

Yes. JuiceFS is built on top a battle tested filesystem, which is used in production for many years. JuiceFS is also fuzzy tested and used by a few customers in production for a few months.

Can I mount JuiceFS using without root?

Yes, JuiceFS could be mounted using juicefs without root. The default directory for caching is /var/jfsCache, you should change that to a directory which you have write permission.

How to contact us?

A: You could reach us using the live chat at the right bottom from any page, or send an email to hello AT