Major Description
Why?
While working on on-premise instalations, the S3 topic is often a blocker: clients are not equiped with this kind of technologies.
Aquiring S3 compatible object stores is not that of an easy /cheap task as it fundamentally redifines what storage is, and clashes hardly with the philosophy they applies.
So far I handled these projects by deploying MinIO (because it is easy to deploy). But on top of shared remote storage performance is mediocre (60 Append of ~500 KB in parallel). Technologies like MinIO are though with attached storage in mind and thus are not adapted to this kind of setup.
I can take concrete examples:
- Medium size governement agencies in developing countries. They just have ISCI SAN bay, and do not have founds to adopt other technologies.
- Large size health organisation. Handling health data in France is subject to numerous security restrictions (HDS certification) thus they have constraints on the datacenter that prevent them from accessing more advanced features.
For these customers, I believe they would be better served with a file based implementation of the blob store.
What?
Provide a file based implementation of the blob store.
Buckets will be emulated via a folder.
Because of it's immutable nature, concurrent file access should not be an issue.
We let the su=ystem administrator the choice of how the file system is set up and distributed, backed up and which mount options are to be set up.
This will be a new BlobStore within `/server/blob/blob-file`.
Propose this blob Store as experimental first.
While a reactive implementation could be attempted with IO Uring (non portable to non Linux system) a first implementation could be as simple as using a boundedElastic thread for the reads.
Attachments
Issue Links
- links to
