thomas_fa

4 ms·

1. 1.▲
   by thomas_fa 4mo ago

   We would wait for Bss data and journal DirectIO and the acking (sending response back to api_server) in the callback function. What you are implying is what s3 actually doing and you can get see from their paper[1] and we are stronger than
2. 2.▲
   by thomas_fa 4mo ago

   Well said and there are some bitter lessons in the storage industry. In my last company we need to disable the disk write cache during each reboot, and we also heard a lot industry stories related to underneath firmware implementation from
3. 3.▲
   by thomas_fa 4mo ago

   Thanks 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
4. 4.▲
   by thomas_fa 4mo ago

   That's a lot of valuable information and thanks for the input. Yes the original blog post is mainly focusing on reducing the metadata overhead due to fsync(), and I got a lot of good feedback from here and a lot of discussion is beyond
5. 5.▲
   by thomas_fa 4mo ago

   Yes, especially for our object storage each putObject would need to create new entry for in the (data)name space which would need fsync for dir fd.
6. 6.▲
   by thomas_fa 4mo ago

   Thanks for the kind words! You check more of our work in https://github.com/fractalbits-labs/fractalbits .
7. 7.▲
   by thomas_fa 4mo ago

   Thanks for the encouragement! Another author here. Yes, if you are interested you can check our another blog [1] for the internal storage engine. Yes, we are limiting the delimeter to "/", to better support posix FS semantics
8. 8.▲
   by thomas_fa 4mo ago

   Yes, that's right. We could go even further, to use the raw devices without relying on any filesystem. We then need to allocate/format raw disk spaces and we can not just open files as simple as right now. It would take some extra
9. 9.▲
   by thomas_fa 4mo ago

   Yes, that has also been pointed out in other threads. Yes this could be very important settings, and even some of common Linux file systems actually don't do that every time and we need to disable the disk writecache during boot up to
10. 10.▲
    by thomas_fa 4mo ago

    Yes, as we mentioned in the post, it is targeted for the virtualized NVME disk and we don't have control for actually issing FUA command. We are also changing to open data files with O_DATA_SYNC to make them work with normal on-prem de
11. 11.▲
    by thomas_fa 4mo ago

    Thanks for pointing it out the mistakes. We should make it clearer, when fsync an opened file descriptor, it would only sync its own metadata. To make it truly persistent, we need to issue another fsync for the directory fd, which would mak
12. 12.▲
    by thomas_fa 5mo ago

    Congrats to the TigerBeetle team's new feature! and it looks like TB has already moved from shared nothing to partially shared disk (object storage) architecture. We are always a big fan of the tigerbeetle engineering and is actually u
13. 13.▲
    by thomas_fa 5mo ago

    Indeed 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
14. 14.▲
    by thomas_fa 5mo ago

    Thanks for the analysis. Interestingly when we first released our low latency s3-compatible storage (1M IOPS, p99 ~5ms)[1], a lot of people asking the same questions why we tried to bring file system semantics (atomic object/folder ren
15. 15.▲
    by thomas_fa 7mo ago

    A lot of good insights here. I am also wandering if they can just simply put different jobs (unclaimed, in-progress, deleted/done) into different directory/prefix, and rely on atomic object rename primitive [1][2][3] to solve the
16. 16.▲
    by thomas_fa 9mo ago

    well I checked the code in their repo，but could not find any snippets as mentioned in the post，which made the claimed perf numbers very suspicious. There was also no cluster configration details in their claim，but you can verify our perform
17. 17.▲
    We Built Another Object Storage (and Why It's Different)(fractalbits.com)

    4 points by thomas_fa 10mo ago|0 comments
18. 18.▲
    Show HN: Fractalbits – S3 compatibe store，1M iops p99～5ms，using Rust and Zig(github.com)

    6 points by thomas_fa 10mo ago|0 comments
19. 19.▲
    by thomas_fa 10mo ago

    FractalBits is an S3-compatible object storage system designed for high performance and low latency. Using our custom-built fractal ART metadata engine, it delivers up to 1 million 4K read IOPS for single bucket with p99 latency ~5ms, at si
20. 20.▲
    Show HN: Fractalbits – S3 compatible high performance storage with Rust and Zig(github.com)

    3 points by thomas_fa 10mo ago|1 comments