YEyencabulator·May 11, 2026
Looks violently non-open-source: https://github.com/fractalbits-labs/fractalbits/issues/8
In Removing fsync from our local storage enginefractalbits-labs
fractalbits
Rust2025–2026
fractalbits-labs / fractalbits
fractalbits
Ultra-high performance distributed storage system in the AI era. Powered by Fractal ART engine, Rust-native, io_uring, with multi-protocol (S3 object storage, POSIX FS, ...)
4Distinct people
10Mentions
0Explicit recommenders
313GitHub stars
What to know before exploring
What it is
Ultra-high performance distributed storage system in the AI era. Powered by Fractal ART engine, Rust-native, io_uring, with multi-protocol (S3 object storage, POSIX FS, ...)
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by week10 dated mentions
Observed mentions: 2025-11-24 19:39:39 UTC to 2026-05-11 18:53:32 UTC. Weeks start Monday, UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| Nov 24 | 2025-11-24 00:00:00 UTC | 2025-12-01 00:00:00 UTC | 2 | 2 | 0 |
| Dec 1 | 2025-12-01 00:00:00 UTC | 2025-12-08 00:00:00 UTC | 2 | 1 | 1 |
| Dec 8 | 2025-12-08 00:00:00 UTC | 2025-12-15 00:00:00 UTC | 1 | 0 | 1 |
| Dec 15 | 2025-12-15 00:00:00 UTC | 2025-12-22 00:00:00 UTC | 0 | 0 | 0 |
| Dec 22 | 2025-12-22 00:00:00 UTC | 2025-12-29 00:00:00 UTC | 0 | 0 | 0 |
| Dec 29 | 2025-12-29 00:00:00 UTC | 2026-01-05 00:00:00 UTC | 0 | 0 | 0 |
| Jan 5 | 2026-01-05 00:00:00 UTC | 2026-01-12 00:00:00 UTC | 0 | 0 | 0 |
| Jan 12 | 2026-01-12 00:00:00 UTC | 2026-01-19 00:00:00 UTC | 0 | 0 | 0 |
| Jan 19 | 2026-01-19 00:00:00 UTC | 2026-01-26 00:00:00 UTC | 0 | 0 | 0 |
| Jan 26 | 2026-01-26 00:00:00 UTC | 2026-02-02 00:00:00 UTC | 0 | 0 | 0 |
| Feb 2 | 2026-02-02 00:00:00 UTC | 2026-02-09 00:00:00 UTC | 0 | 0 | 0 |
| Feb 9 | 2026-02-09 00:00:00 UTC | 2026-02-16 00:00:00 UTC | 0 | 0 | 0 |
| Feb 16 | 2026-02-16 00:00:00 UTC | 2026-02-23 00:00:00 UTC | 0 | 0 | 0 |
| Feb 23 | 2026-02-23 00:00:00 UTC | 2026-03-02 00:00:00 UTC | 0 | 0 | 0 |
| Mar 2 | 2026-03-02 00:00:00 UTC | 2026-03-09 00:00:00 UTC | 0 | 0 | 0 |
| Mar 9 | 2026-03-09 00:00:00 UTC | 2026-03-16 00:00:00 UTC | 0 | 0 | 0 |
| Mar 16 | 2026-03-16 00:00:00 UTC | 2026-03-23 00:00:00 UTC | 0 | 0 | 0 |
| Mar 23 | 2026-03-23 00:00:00 UTC | 2026-03-30 00:00:00 UTC | 0 | 0 | 0 |
| Mar 30 | 2026-03-30 00:00:00 UTC | 2026-04-06 00:00:00 UTC | 0 | 0 | 0 |
| Apr 6 | 2026-04-06 00:00:00 UTC | 2026-04-13 00:00:00 UTC | 2 | 0 | 2 |
| Apr 13 | 2026-04-13 00:00:00 UTC | 2026-04-20 00:00:00 UTC | 0 | 0 | 0 |
| Apr 20 | 2026-04-20 00:00:00 UTC | 2026-04-27 00:00:00 UTC | 0 | 0 | 0 |
| Apr 27 | 2026-04-27 00:00:00 UTC | 2026-05-04 00:00:00 UTC | 0 | 0 | 0 |
| May 4 | 2026-05-04 00:00:00 UTC | 2026-05-11 00:00:00 UTC | 2 | 0 | 2 |
| May 11 | 2026-05-11 00:00:00 UTC | 2026-05-18 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
10 sourcesThanks for the feedback, since I have relied in other thread related to O_DSYNC which a lot of folks have already suggested, and I will not repeat it here.
For the benchmark results, and they were mainly due to metadata management. We have implemented our own KV store, see internal here [1], which is more efficient than ext4 namespace management, even after doing very aggressive fs tuning for that [2] (plus 65536 sharding for each leveled dir).
[1] https://fractalbits.com/blog/metadata-engine-for-our-object-...
[2] https://github.com/fractalbits-labs/fractalbits/commit/12109...
In Removing fsync from our local storage engineThanks for the kind words! You check more of our work in https://github.com/fractalbits-labs/fractalbits.
In Removing fsync from our local storage engineWe have advanced to building S3 stores with claude code - impressive:
https://github.com/fractalbits-labs/fractalbits-main/graphs/...
In S3 FilesIndeed this is not an easy problem. And our s3-compatible system do support the atomic rename with extended protocol in a graceful way, see the demo with our tool [1].
[1] https://github.com/fractalbits-labs/fractalbits-main/tree/ma...
In S3 Filesgithub page: https://github.com/fractalbits-labs/fractalbits-main
In We built another object storageYes, you can check the code here https://github.com/fractalbits-labs/fractalbits-main/blob/ma.... For each type of requests we have a separate handler for that.
The basic tests are here: https://github.com/fractalbits-labs/fractalbits-main/blob/ma.... We also have fuzz tests internally, which could be open once we feel it is ready.
In Show HN: S3 compatible store with 1M IOPS(4K-R,p99~5ms), BYOC in 5min with rustShow HN: S3 compatible store with 1M IOPS(4K-R,p99~5ms), BYOC in 5min with rust
23 points · Open discussionShow HN: Fractalbits – S3 compatibe store，1M iops p99～5ms，using Rust and Zig
6 points · Open discussionShow HN: Fractalbits – S3 compatible high performance storage with Rust and Zig
3 points · Open discussion