Yes, we can use `#amazon-s3` as the anchor, then the name could be long, for example, `#digitalocean-spaces-object-storage`), and it will not work in Chinese.
Your suggestion is better than current one, we will use that, thanks!
215 karma · joined January 2, 2014
Founder and CEO at Juicedata, Inc.
davies@juicedata.io
Your suggestion is better than current one, we will use that, thanks!
One thing that bothers us: we have not figure a way to name the anchor that both work in Github (`<span id='aws-s3'/>`) and Docusaurus (`{#aws-s3}`), for example [2]. Any ideas?
[1] https://juicefs.com/docs/community/introduction [2] https://github.com/juicedata/juicefs/blob/main/docs/en/how_t...
JuiceFS have made lots of improvements since open sourced in Jan 2021[1]. For example, people were concerning on persistency of Redis, so we added PostgreSQL and MySQL as meta engines, are working added support FoundationDB also.
There are several companies using it in production already, more people are evaluating it[2].
[1] https://news.ycombinator.com/item?id=25747215 [2] https://github.com/juicedata/juicefs/blob/main/ADOPTERS.md
They require a cluster of machines, the replicate the data across them, using either expensive EBS or local disk (a few larger instance to pick).
Maintaining them well is another burden. The cool idea of JuiceFS is to shift the maintenance to hosted Redis and S3.
But the way, A S3 gateway is on our roadmap, you can spin up an S3 gateway for JuiceFS, and talk to that using existing S3 SDK. This only make sense when you have other applications outside of Lambda using JuiceFS.
The difficulty of using S3 as metadata is that they is not way to persistent metadata under 1 ms, for example, created a symlink, it will take more than 20ms, or you may lose it.
With en external persisted database, we could have the ACID for metadata operations. Also, the meta is the source of truth, whenever the object store is out of sync (losing or leaking a object), the whole file system is still consistent, rather than part of a file is corrupted, should be safer than put everything into S3.
The database is the key, redis is our first choice, we will add support to other databases in future.
We have put lots of effort to make the operations interruptible when either meta or object store is slow or down. There are a few cases that the `close` can't be interrupted, we can still abort the FUSE connection or kill the JuiceFS process, then all the operation are canceled.
In general, JuiceFS is built on FUSE, so we can have more control on it.
The recent GFS may have multiple masters[1], but they are separate namespace, similar to HDFS federation.
JuiceFS was initial designed for big data workload in Cloud, and we have tens of paying customer use it in this use case.
For NAS use case, the latency would be slower when case missed, but the overall IOPS could be higher. In the case of overwhelmed HDD, the latency could also go up to hundreds of milliseconds. We have pay lots of effort to improve the caching (in kernel and on disk) and prefetching. The overall performance is comparable to HDD over NFS.
I have saw people asking SQL database support for s3ql, to make s3ql accessible from multiple machines, right now, JuiceFS could be a choice.
The POSIX and FUSE stuff was learned from MooseFS, but changed to use read-only chunk, and merge them together, and do compaction in background. Since most of object storage provide eventual consistency, the model work pretty well, also simplify the burden on cache eviction. In order to access object store in parallel, we divide the chunk into smaller blocks (4MB), which is also a good unit for caching.
The Hadoop SDK (not released yet) was learned from HDFS.
One key thing in the implementation is to use Redis transaction to guarantee atomicy on metadata operations, otherwise we will get into millions of random bugs.
If you run it on your own, please pay attention on the persistency options and HA solution, there should be plenty of article on these.
Yes, please use `rediss://host:port/`
> 2. Is there any access control and if there is who enforces it?
You may specify port 0 to disable the non-TLS port completely. To enable only TLS on the default Redis port, use:
-port 0 -tls-port 6379
My guest is that Avere could require a cluster of nodes as the fast layer for write and synchronization. In JuiceFS, Redis is used for synchronization and persisting metadata. Local SSD could used for data read-caching, not for writing.
JuiceFS is in production for 3+ years, we have not find much challenge that was difficult with this design, since it's borrowed from GFS, HDFS and MooseFS, have be proved in production for more than 10 years. I'd like to hear what's the challenge you were facing.
[1] https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/...
We can have a SDK to access JuiceFS from Lambda, similar to S3 SDK, when you need to use JuiceFS outside of Lambda.
Same to Fargate, we can not mount JuiceFS in Farget because of lacking FUSE permission, people are asking for it[1].
1. Unlinked file remain accessible, when it's unlink from same machine. 2. mmap is supported. 3. atomic rename is supported. 4. Is there atomic append in POSIX? 5. range lock is supported. 6. the consistency mode is open-after-close, which means once a file is closed, you can open and read the latest data.
Ceph is great, if you can master the complexity under the hood, MinIO + Redis + JuiceFS could be the easier answer for beginners.
I'm the founder of JuiceFS, would like to answer any questions here.