Compare with SeaweedFS

[alberk8]

Is there any comparison done against SeaweeFS ?
Is the underlying storage of object in rustfs just a plain file in the host filesystem?. If so, will there be performance issues tied to the OS filesystem when number of object increase to the millions.

[loverustfs]

We don't have this comparative performance report.
In fact, we have many ways to solve the performance concerns.

[alberk8]

Thank you for the prompt reply.
One other thing that I find very limiting is the way expansion in Minio and I guess extends to RustFs is the way storage expansion works. From my understanding, there is no way to expand by add disk(s) in a single node multiple disks or multi host multi disks cluster. Is there any plan to address this limitation.

[loverustfs]

It is impossible to increase capacity by adding a single node.

Because the design pattern is designed like this:

1. Assume there are 4 servers and 16 hard disks;
2. He bundled the disks of the 4 servers into a stripe.
3. Adding a new hard disk will cause all the stripes to change, and the data complexity and IO requests will increase.

Therefore, we did not design adding a single node to the cluster to expand capacity.

[alberk8]

Thanks again for the reply. I love that RustFs is doing what Minio is not doing with the licensing and rust lang.
But the Minio setup style is more expensive as it involve pre-planning and non trivial (cost wise) to expand as you grow.

[loverustfs]

Thanks again for the reply. I love that RustFs is doing what Minio is not doing with the licensing and rust lang.
But the Minio setup style is more expensive as it involve pre-planning and non trivial (cost wise) to expand as you grow.

Ceph can achieve this function, but it is too complicated.

[alberk8]

I agree that Ceph is too complex and costly to setup. In my honest opinion, I feel that this project should make a detour on the storage side to allow users to start small and allow for seamless ability to scale up.

[loverustfs]

We are still catching up with MinIO. At present, there is no plan to promote this area.

Theoretically, it can be achieved:

1. Add a server;

2. The system starts to calculate its own IO and CPU consumption;

3. Divide into old EC and new EC according to time;

4. Read the old EC according to the old one, and read the new one according to the new stripe value.

The risks are also great:

1. If the user sets the default stripe information, the new route will fail;

2. In the production environment, if a machine is expanded and there is no window time for EC and data rebalancing, the same risk as Ceph will occur.

Therefore, we think that the design of MinIO seems to be fine from now on.

It is recommended to consider the growth of data volume in the next three years when expanding capacity.

Accept the advantages of a product and also accept its disadvantages.

This is a difficult multiple-choice question.

[alberk8]

Thank you for the detailed project approach on this subject. Hope for this project to grow fast and look forward to the future on more features while maintaining compatibility.