211–220 of 338 posts
What is the purpose of MinIO, Seaweedfs and similar object storage systems? They lack durability guarantees provided by S3 and GCS. They lack "infinite" storage promise contrary to S3 and GCS. They lack "infinite" bandwidth unlike S3 and GCS. They are more expensive than other storage options, unlike S3 and GCS.
What is the purpose of MinIO, Seaweedfs and similar object storage systems? They lack durability guarantees provided by S3 and GCS. They lack "infinite" storage promise contrary to S3 and GCS. They lack "infinite" bandwidth unlike S3 and GCS. They are more expensive than other storage options, unlike S3 and GCS.
For example, we were running a 20 node k8s cluster for our Cortex (distributed Prometheus) install, monitoring about 30k servers around the world, and it was generating a bit over a TB of data a day. It was a lot more cost effective and performant to create a minio cluster for that data than to use S3.
Also, you can get durability with minio with multi cluster replication.
> For enterprise support and actively maintained versions, please see [MinIO AIStor] Naming the product “AIStor” is one of the most blatant forced AI branding pivots I’ve seen.
And the naming conflicts with NVidia's AIStore ( https://github.com/NVIDIA/aistore ). The two products are extremely similar. I don't know which came first, but Minio is going to want to do another pivot very soon if they want to survive. I doubt they have the resources to stand up to NVidia's army of extremely well-paid IP lawyers.
What is the purpose of MinIO, Seaweedfs and similar object storage systems? They lack durability guarantees provided by S3 and GCS. They lack "infinite" storage promise contrary to S3 and GCS. They lack "infinite" bandwidth unlike S3 and GCS. They are more expensive than other storage options, unlike S3 and GCS.
Earlier quoted context omitted.
I think the criticism (just interpreting the post, don’t know anything about the technical situation) is that the complication is not necessary/worthwhile. POSIX can be complicated, but it puts you in a nice ecosystem, so for some use-cases complex POSIX support is not over complicated. It is just… appropriately complicated.
Sure, but then you can make that argument about any of the features in Minio, in which case the parent's argument about Minio as a whole being overcomplicated is invalidated. Probably the more sensible way to look at things is "value / complexity" or "bang for buck", but even there I think POSIX loses since it's relatively little value for a relatively large amount of complexity.
> Gaslight community when rightfully annoyed
> Kill off primary product
> Offer same product with AI slapped on the name to enterprise customers.
Good riddance Minio, and goodbye!
Earlier quoted context omitted.
My point was even 45drives virtualization of Ceph host roles to squeeze the entire setup into a single box was not a "hobby" grade project. I don't understand yet exactly what MinIO would add on top of that to make it relevant at any scale. I'll peruse the manual on the weekend, because their main site was not helpful. Thanks for trying though ¯\_(ツ)_/¯
What I tried to say (perhaps not successfully) was that core Ceph knows nothing about S3. One gets S3 endpoint capability from the radosgw which is not a required component in a ceph cluster.
I've been using Minio in ZeroFS' [0] CI (a POSIX compliant filesystem that works on top of s3). I guess I'll switch to MicroCeph [1]. [0] https://github.com/Barre/ZeroFS [1] https://canonical-microceph.readthedocs-hosted.com/stable/
What is the use case for implementing a POSIX filesystem on top of an object store? I remember reading this article a few years ago, which happens to be by the minio folks: https://blog.min.io/filesystem-on-object-store-is-a-bad-idea...
The use case is fully stateless infrastructure: your file/database servers become disposable and interchangeable (no "pets"), because all state lives in S3. This dramatically simplifies operations, scaling, and disaster recovery, and it's cheap since S3 (or at least, S3 compatible services) storage costs are very low.
The MinIO article's criticisms don't really apply here because ZeroFS doesn't store files 1:1 to S3. It uses an LSM-tree database backed by S3, which allows it to implement proper POSIX semantics with actual performance.
I've been working on https://github.com/uroni/hs5 as a replacement with similar goals to early minio. The core is stable at this point, but the user/policy management and the web interface is still in the works.
Looks like a great alternative.