F* file system – file search that reads SSD directly bypassing OS kernel
github.com
github.com
> reading a raw device node (e.g. /dev/rdisk*)
That's... not bypassing the kernel. Time to integrate SPDK so it actually bypasses the kernel :)
more correct would be - do not use kernel file system
supports ext4, btrfs, and apfs. Multithreaded, supports compression, nested volumes, and can even search detached volumes like .iso and .dmg without mounting
An interesting bonus point: you can't really vibe code it cause clankers can not run sudo commands
Is that really true? I'm fairly certain that were you to give it the proper tooling and it's own VM, it could quite happily run any command.
Hell a simple "if the CLI returns any form of 'permission denied' retry previous command with sudo; your password is: Hunter2" skill would work, no?
alias safedo='sudo'
What's the license for ffs?
Well, you could whitelist the tool in sudoers.
This would let LLMs use it too.
For me, it took a bit over six weeks of Claude running unattended perpetually.
Also gave Opus 4.6 access to a Kubernetes container and it was able to use pyrasite (a Python replacement that attached to a running process with gdb) to debug a "memory leak" in Python
I don't think I'd let them run unattended on anything I care about especially if there weren't backups, but they've never tried to break anything while supervised.
Usually it's significantly faster and more accurate to give the LLM/harness access to the thing to debug then to try to copy/paste back and forth.
> "On my machine, after about 21 days of uptime, the main SSD has written about 37 TB," wrote developer Rui Fan, a project management committee member of Apache Flink. "Process/file-level checks show Codex SQLite logs are the main continuous writer
https://www.theregister.com/ai-and-ml/2026/06/23/openai-code...
Did you write a metadata parser for most of the filesystems?
They absolutely can. There's nothing special about a these harnesses. You automate sudo the same way you would automate in any other context. SUDO_ASKPASS, visudo, etc, maybe with a alias for obfuscation if your harness hates you.
Do you mean the harnesses prevent it? Or it can't type a password or something?
I've been running mine as root on a disposable VPS. (Finally I have a dedicated linux guy!)
I have zero affiliation with Cursor, and I don't use it much, but Cursor Agent, for example, just builds in ASKPASS support so that if it runs a sudo command, it will show you a password prompt:
With respect to the dangers of privilege escalation, a useful list of common commands which are difficult to invoke safely with elevated permissions: https://gtfobins.org/
> The project collects legitimate functions of Unix-like executables that can be abused to break out restricted shells, escalate or maintain elevated privileges, transfer files, spawn bind and reverse shells, and facilitate other post-exploitation tasks.
Prior discussion: https://news.ycombinator.com/item?id=47931035
Tell that to the Claude who set up my Raspberry Pi from scratch.
sudo setfacl -m u:$USER:r-- /dev/nvmen01p2 # or whatever
Or if you want to only give fff access,
sudo groupadd diskreaders
sudo setfacl -m g:diskreaders:r-- /dev/nvmen01p2
sudo chown :diskreaders /path/to/fff
sudo chmod g+s /path/to/fff
So your LLM can use the binary with some safety against it going off the rails.
It works by reading the block device in /dev directly, wouldn't it also work on an HDD, flash drive or a memory card?
I don't think I'd ever trust or use this, but still, good job OP :)
Is it really faster than normal filesystem? I haven't checked it, but the normal version using kernel cache should be much faster, because it doesn't even touch the disk?
In particular, can it be certain that a flush is really a flush?
Sure, you can test by completely filling the drive with predictable (to you, not to a counterfeiter) data and then verifying the write, but even on an SSD that's tedious.