Hacker News: uroni

New comment by uroni in "MinIO Is Dead, Long Live MinIO"

uroni — Sun, 01 Mar 2026 00:13:31 +0000

There is a lot of software that directly implements the HTTP S3 API. That API is also documented by Amazon.

E.g. the last implementation I saw was by DuckDB https://github.com/duckdb/duckdb-httpfs/blob/main/src/s3fs.c...

New comment by uroni in "MinIO Is Dead, Long Live MinIO"

uroni — Sat, 28 Feb 2026 23:42:20 +0000

AGPL is "a plague" by design (viral). It has the explicit goal that any improvements flow back to the community project and the virality is a necessary building block for this. It is an elegant solution to a tragedy of the commons problem.

Companies like MinIO extending the virality beyond the single software/work, even though not intended by license, gives it a bad reputation. They have fixed https://min.io/compliance now, but I guess it does not matter anymore.

New comment by uroni in "MinIO Is Dead, Long Live MinIO"

uroni — Sat, 28 Feb 2026 23:06:34 +0000

I never understood why one would use MinIO over Ceph for serious (multi-node) use. Sure, it might be easier to setup initially, but Ceph would be more likely to work.

For the single node use-case, I'm working on https://github.com/uroni/hs5 . The S3 API surface is large, but at this point it covers the basics. By limiting the goals I hope it will be maintainable.

Show HN: HS5 – Open Source fast single-node S3 compatible object storage

uroni — Mon, 16 Feb 2026 11:21:11 +0000

HS5 ([website](https://hs5.eu) | [GitHub](https://github.com/uroni/hs5)) is a high-performance scale-up self-hosted S3 compatible object storage server. It is ideal for use cases where single-node scaling, performance, and data-loss risk are acceptable, or as a building block for more robust systems. For example use cases might be local testing environments or temporary storage for data processing workflows.

HS5 features a web interface for managing buckets and users.

License: LGPLv3+

I was previously using MinIO for my single node object storage needs, but it did not scale well with many objects since it creates multiple files for each object. Now it does not aim to solve the single-node use case anymore anyway and is unmaintained as well.

Some technical details: It is written in C++ since I already had an implementation of the main object storage from another project ( SingleFileStorage.cpp ). For the main object to disk location mapping it uses LMDB (a copy-on-write memory mapped database). Once the database memory is mapped, the mapping operations run at in-memory database speeds. The copy-on-write makes writing (small) changes slower. To mitigate this there is an optional WAL mode, where changes are committed to a WAL, then asynchronously committed to the LMDB. Alternatively there is a manual commit mode where commit is done via writing to a special object. Using this might be interesting for bulk-loading or for testing use cases.

Comments URL: https://news.ycombinator.com/item?id=47033721

Points: 2

# Comments: 0

New comment by uroni in "Sparse File LRU Cache"

uroni — Sun, 01 Feb 2026 11:06:43 +0000

I’ve used this technique in the past, and the problem is that the way some file systems perform the file‑offset‑to‑disk‑location mapping is not scalable. It might always be fine with 512 MB files, but I worked with large files and millions of extents, and it ran into issues, including out‑of‑memory errors on Linux with XFS.

The XFS issue has since been fixed (though you often have no control over which Linux version your program runs on), but in general I’d say it’s better to do such mapping in user space. In this case, there is a RocksDB present anyway, so this would come at no performance cost.

New comment by uroni in "MinIO is now in maintenance-mode"

uroni — Wed, 03 Dec 2025 17:53:29 +0000

It uses LMDB, so if the object mapping fits in memory that should be pretty optimal for reading, while using the build-in Linux page cache and not a separate one (important for testing use cases). For write/deletes it has a bit of write-amplification due to the copy-on-write btree. I've implemented a separate, optional WAL for this and also a mode where writes/delete can be bundeled in a transaction, but in practice I think the performance difference should not matter.

W.r.t. filesystem: Yes, aware of this. Initially used minio and also implemented the use case directly on XFS as well and only had problems at larger scales (that still fit on a machine) with it. Ceph went into a similar direction with BlueStore (reimplementing the filesystem, but with RocksDB).

New comment by uroni in "MinIO is now in maintenance-mode"

uroni — Wed, 03 Dec 2025 17:37:44 +0000

I'm not a contributor to Minio. This is its own separate thing.

I do have a separate AGPL project (see github) where I have nearly all of the copyright and have looked into how one would be able to enforce this in the US at some point and it did look pretty bleak -- it is a civil suit where you have to show damages etc. but IANAL.

I did not like the FUD they were spreading about AGPL at the time since it is a good license for end-user applications.

New comment by uroni in "MinIO is now in maintenance-mode"

uroni — Wed, 03 Dec 2025 16:58:32 +0000

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.

New comment by uroni in "How AWS S3 serves 1 petabyte per second on top of slow HDDs"

uroni — Wed, 24 Sep 2025 17:12:09 +0000

I'm working on something that might be suited for this use-case at https://github.com/uroni/hs5 (not ready for production yet).

It would still need a resilience/cache layer like ZFS, though.