←back to thread

An intro to DeepSeek's distributed file system

(maknee.github.io)
621 points sebg | 2 comments | 17 Apr 25 12:50 UTC | HN request time: 0.429s | source
Show context
snthpy ◴[17 Apr 25 16:21 UTC] No.43719011[source]▶
Similar to the SeaweedFS question in sibling comment, how does this compare to JuiceFS?

In particular for my homelab setup I'm planning to run JuiceFS on top of S3 Garage. I know garage is only replication without any erasure coding or sharding so it's not really comparable but I don't need all that and it looked at lot simpler to set up to me.

replies(1): >>43719152 #
1. huntaub ◴[17 Apr 25 16:32 UTC] No.43719152[source]▶
It's a very different architecture. 3FS is storing everything on SSDs, which makes it extremely expensive but also low latency (think ~100-300us for access). JuiceFS stores data in S3, which is extremely cheap but very high latency (~20-60ms for access). The performance scalability should be pretty similar, if you're able to tolerate the latency numbers. Of course, they both use databases for the metadata layer, so assuming you pick the same one -- the metadata performance should also be similar.
replies(1): >>43726541 #
2. snthpy ◴[18 Apr 25 10:01 UTC] No.43726541[source]▶
Thanks, that's good to know.

For the most part I can live with the latency. For frequently or repeatedly accessed files I believe JuiceFS also has a caching layer to bring down the latency on those. My use cases are quite different from what DeepSeek requires. I was just curious whether I needed to investigate 3FS since it's the new kid on the block.

What appeals to me about JuiceFS is that I can easily mount it into my containers for a distributed FS on a small cluster for some resilience. It looked simpler than Ceph or GlusterFS for that and it's backed by S3 so that I could swap out my S3 Garage setup for a cloud based S3 backend if required.