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.
We made our filesystem 47× faster by deleting it
21–30 of 43 posts
Re: We made our filesystem 47× faster by deleting it
#22Isn'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.
Re: We made our filesystem 47× faster by deleting it
#23The 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.
Could you not find the reader view button?
Re: We made our filesystem 47× faster by deleting it
#24>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?
Re: We made our filesystem 47× faster by deleting it
#25Title: 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…
[deleted]
Re: We made our filesystem 47× faster by deleting it
#26Title: 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…
[deleted]
Re: We made our filesystem 47× faster by deleting it
#27Title: 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…
fair point. that's the title we used on our X article and i copy-pasted. updated the article's actual title.
Re: We made our filesystem 47× faster by deleting it
#28Isn'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.
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.
Re: We made our filesystem 47× faster by deleting it
#29I'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.
Re: We made our filesystem 47× faster by deleting it
#30Is 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.
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.