I've found that tar processing tends to dominate the time used to do anything with standard OCI layers. I have a more efficient format (that splits apart the layer into metadata+chunks) that I'm open sourcing soon if y'all are interested in using it.
> Isn't it really obvious that a user space fs will always be slow, and especially slow with small files?
Small files seem like the perfect case for a user space fs... depending on what you mean by user space fs. If you mean interfacing with a FUSE (or similar) filesystem by using syscalls in your program to context switch into the kernel, then context switch to the userspace FUSE layer, then send it back to the kernel and then back to your program ... that will be especially slow with small files where date bytes per context switch is small. OTOH, if you mean a user space fs where your program has a built in filesystem it can access without context switching, then that will be of benefit ... especially if the files are small enough that you can pack multiple files into a single page.
A filesystem is a database, it is a type of key value storage. there is a hierarchical lookup key that points you to an unstructured block of data.
Many databases(berkleydb, postgresql, sqlite) are then built on this unstructured database. There is absolutely nothing indicating that putting putting a key value database with hierarchical keys and unstructured blocks in a single file will be slow.
It could be, naive indexing or rebalancing could be very slow. But it does not have to be. In fact berkleydb is a neat case study here. superficially it is a ridiculously simple key value store, why does such a simple thing even need to exist, or have such a long lived presence. It turns out building the efficient structures needed to work with slow non-volatile storage is non-trivial. Early mysql used berkleydb as a low level storage engine. Note that mysql main selling point was speed before correctness.
See also: Virtual machines another ubiquitous case of a filesystem in userspace.
It's something completely different. A database like SQLite runs in the same process as the application
All the filesystem calls go through the kernel. A userspace file system is another process.
It's not like SQLite, it's more like Postgres. Try sending a few hundred thousand small queries to Postgres, and be surprised how slow it's going to be.
The file system api is not like sql that allows complex queries. It's a lot of tiny and simple requests that assume very low latency.
SQLite is in-process. A user space file system is another process. Like Postgres if we want to compare fs with dbs. And Postgres is slow for many small queries, like a userspace file system.
Is anyone here using this software? How do you integrate it with your agent workflow? Do you run agents in editor (Zed, VS Code, Cursor, whatever)?
Have you tried the sync feature?
Edit: FML why is this being downvoted? At least have the decency of explaining, I'm happy to adjust my conduct but I can't do so if I don't know what I did wrong.
I can only guess at the actions of others, but I would guess it’s because your comment is a tangent and at best only vaguely related to the featured article?
The article is really about solving a particular problem with the backend of their infrastructure. Discussion about VMs, Linux kernel syscalls, file systems (virtual, FUSE, etc) would all be relevant.
Your comment is a question about whether and how people use the software itself, which is pretty unrelated to the article.
It’s a bit like an article about Porsche identifying a particular engineering nuance in their fuel injectors, and how things didn’t work the way they thought at a low level, and how they solved it once they realized it. And then you come in with a comment about what people like to do with their Porsches. Like, sure, it involves the same company but what would that have to do with the underlying article on automotive engineering?
Combine that with a growing disdain for the insistence of certain segments of the tech scene to make everything about agentic workflows, (an echo to the constant evangelism of cryptocurrencies or blockchain in the recent past) and you have a recipe for downvotes.
This is pretty common on this forum though. Many times the comments section becomes mostly about things that are not necessarily directly related to the article but remain related to the bigger thing the article is about.
You’re not wrong, and this is speculation, but I suspect you’re just missing the subtext I added in my edit: that some people are burnt out on the evangelism of agentic workflows in the same way they were about blockchain or whatnot.
it depends where you want your agent to live. inside the sandbox, start a sandbox via the CLI and run your agents/do your dev in there. outside the sandbox, you'd configure your harness to use the MCP / skill integration. here's the guide: https://docs.microsandbox.dev/getting-started/agents
if you're building a harness, the SDK provides better integration. let me know if you hit any blockers.
People are generally sick of AI, and of people who bring AI up in every single comment thread. The downvoters may not realise that TFA is by an AI company, about an AI product, making your comment tangentially relevant, and not (strictly-speaking) an example of the behaviour they're fed up with.
Heh yeah it very well could be. I am also fed up with AI everywhere but I don't go out downvoting everyone and everything who mentions it - and definitely not where the whole context is about it.
I don't think you can blame that on FUSE in general. If not some quirk of your local setup then maybe the particular implementation you were using - what sort of volume was it?
Title: How we made our OCI filesystem 47× faster
Your coworker/other account, messed it up last time you submitted it too: We made our sandbox filesystem 47× faster by deleting it https://news.ycombinator.com/item?id=48195883
> Otherwise please use the original title, unless it is misleading or linkbait; don't editorialize.
You're linkbaiting.. the opposite of the guideline
https://news.ycombinator.com/newsguidelines.html
fair point. that's the title we used on our X article and i copy-pasted. updated the article's actual title.
I've found that tar processing tends to dominate the time used to do anything with standard OCI layers. I have a more efficient format (that splits apart the layer into metadata+chunks) that I'm open sourcing soon if y'all are interested in using it.
interested. is the split for dedup, parallel pulls, or lazy loading specific files? maybe all.
we've played with some chunking ideas on our end but haven't landed on a format. drop a link when it's out.
Isn't it really obvious that a user space fs will always be slow, and especially slow with small files?
I don't know the purpose of microsandbox, but such an article doesn't give me great confidence in exploring it further.
> Isn't it really obvious that a user space fs will always be slow, and especially slow with small files?
Small files seem like the perfect case for a user space fs... depending on what you mean by user space fs. If you mean interfacing with a FUSE (or similar) filesystem by using syscalls in your program to context switch into the kernel, then context switch to the userspace FUSE layer, then send it back to the kernel and then back to your program ... that will be especially slow with small files where date bytes per context switch is small. OTOH, if you mean a user space fs where your program has a built in filesystem it can access without context switching, then that will be of benefit ... especially if the files are small enough that you can pack multiple files into a single page.
Not obvious to me.
A filesystem is a database, it is a type of key value storage. there is a hierarchical lookup key that points you to an unstructured block of data.
Many databases(berkleydb, postgresql, sqlite) are then built on this unstructured database. There is absolutely nothing indicating that putting putting a key value database with hierarchical keys and unstructured blocks in a single file will be slow.
It could be, naive indexing or rebalancing could be very slow. But it does not have to be. In fact berkleydb is a neat case study here. superficially it is a ridiculously simple key value store, why does such a simple thing even need to exist, or have such a long lived presence. It turns out building the efficient structures needed to work with slow non-volatile storage is non-trivial. Early mysql used berkleydb as a low level storage engine. Note that mysql main selling point was speed before correctness.
See also: Virtual machines another ubiquitous case of a filesystem in userspace.
It's something completely different. A database like SQLite runs in the same process as the application
All the filesystem calls go through the kernel. A userspace file system is another process.
It's not like SQLite, it's more like Postgres. Try sending a few hundred thousand small queries to Postgres, and be surprised how slow it's going to be.
The file system api is not like sql that allows complex queries. It's a lot of tiny and simple requests that assume very low latency.
Sqlite is essentially a user space queryable file system and it can be faster than writing to file system directly while working with small files.
SQLite is in-process. A user space file system is another process. Like Postgres if we want to compare fs with dbs. And Postgres is slow for many small queries, like a userspace file system.
That's such a HN title!
And the content. A number of smart design decisions, and analysis of what was wrong with the previous versions.
Also, it's a great illustration of the benefits of layered, modular design that Linux sports: it allows to mix and match parts to build what you need.
Sounds like a title you’d read on the satirical version of HN in a TV show like Silicon Valley
Is anyone here using this software? How do you integrate it with your agent workflow? Do you run agents in editor (Zed, VS Code, Cursor, whatever)?
Have you tried the sync feature?
Edit: FML why is this being downvoted? At least have the decency of explaining, I'm happy to adjust my conduct but I can't do so if I don't know what I did wrong.
I can only guess at the actions of others, but I would guess it’s because your comment is a tangent and at best only vaguely related to the featured article?
The article is really about solving a particular problem with the backend of their infrastructure. Discussion about VMs, Linux kernel syscalls, file systems (virtual, FUSE, etc) would all be relevant.
Your comment is a question about whether and how people use the software itself, which is pretty unrelated to the article.
It’s a bit like an article about Porsche identifying a particular engineering nuance in their fuel injectors, and how things didn’t work the way they thought at a low level, and how they solved it once they realized it. And then you come in with a comment about what people like to do with their Porsches. Like, sure, it involves the same company but what would that have to do with the underlying article on automotive engineering?
Combine that with a growing disdain for the insistence of certain segments of the tech scene to make everything about agentic workflows, (an echo to the constant evangelism of cryptocurrencies or blockchain in the recent past) and you have a recipe for downvotes.
This is pretty common on this forum though. Many times the comments section becomes mostly about things that are not necessarily directly related to the article but remain related to the bigger thing the article is about.
Oh well. :) Thanks for your insight anyway.
You’re not wrong, and this is speculation, but I suspect you’re just missing the subtext I added in my edit: that some people are burnt out on the evangelism of agentic workflows in the same way they were about blockchain or whatnot.
it depends where you want your agent to live. inside the sandbox, start a sandbox via the CLI and run your agents/do your dev in there. outside the sandbox, you'd configure your harness to use the MCP / skill integration. here's the guide: https://docs.microsandbox.dev/getting-started/agents
if you're building a harness, the SDK provides better integration. let me know if you hit any blockers.
for sync, it's currently in the works.
People are generally sick of AI, and of people who bring AI up in every single comment thread. The downvoters may not realise that TFA is by an AI company, about an AI product, making your comment tangentially relevant, and not (strictly-speaking) an example of the behaviour they're fed up with.
Heh yeah it very well could be. I am also fed up with AI everywhere but I don't go out downvoting everyone and everything who mentions it - and definitely not where the whole context is about it.
If your problem could be solved without FUSE, it probably should!
that's the tldr. we used fuse and we learnt we shouldn't for a sandbox filesystem
>Every file operation inside the VM had to bounce out to the host through FUSE
Lol, yeah that was your mistake. FUSE is a phenomenal idea but anyone who has used it knows how slow it can be.
FUSE is not slow. Our distributed file system pipes over 70 GB/a through a single mount point.
70GB/s or 70 Gbps?
OP said 70GB/a so I'm gonna assume that's gigabytes per annum /j
I have learned first hand with my agentic workflow as it took 1 hour to compile rust instead of 6 seconds.
I don't think you can blame that on FUSE in general. If not some quirk of your local setup then maybe the particular implementation you were using - what sort of volume was it?
it was dirty pages, kernel was artificially throttling it inside a sandbox.
Especially compared to direct virtio access to physical volume.
The site is impossible for me to read due to the colors. I went to lynx and i looks like it is about a file system in a VM.
thanks, that's useful feedback. is this also the case in light mode? i'll take a look and tighten the contrast.
Could you not find the reader view button?
You made your filesystem 47x slower by NIHing it