|
|
Log in / Subscribe / Register

The ABI status of filesystem formats

The ABI status of filesystem formats

Posted Oct 8, 2020 17:46 UTC (Thu) by sbaugh (guest, #103291)
Parent article: The ABI status of filesystem formats

Triplett's library sounds interesting and somewhat-generally-useful, actually. Repeating the description here:

>The short version is that I needed a library to rapidly turn
>dynamically-obtained data into a set of disk blocks to be served
>on-the-fly as a software-defined disk, and then mounted on the other
>side of that interface by the Linux kernel. Turns out that's *many
>orders of magnitude* faster than any kind of network filesystem like
>NFS. It's slightly similar to a vvfat for ext4. The less blocks it can
>generate and account for and cache, the faster it can run, and
>microseconds matter.

It's an unusual use case, but it doesn't seem like one which is totally unacceptable. I could imagine using it myself. It would be nice to see it upstreamed to e2fsprogs.


to post comments

The ABI status of filesystem formats

Posted Oct 8, 2020 19:51 UTC (Thu) by khim (subscriber, #9252) [Link]

Agree 100% there. I'm not sure I would want to push e2fsprogs to support it, but it sounds precisely as something much more useful then author who made this tool thinks.

I only hope that's not something which differentiates the product which he is developing from other such tools and it could be open-sourced and shared.

The ABI status of filesystem formats

Posted Oct 11, 2020 21:23 UTC (Sun) by WolfWings (subscriber, #56790) [Link]

...this seems like they're simply using the wrong filesystem entirely. ROMFS has been around since somewhere in the 2.6's and compiles down to literally a couple kilobytes of total binary size in most cases.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds