Post #738580

2026-03-23 06:17 UTC

So... codex wrote a qcow2 block device driver for the kernel in Rust. It&#39;s at least 10% faster than nbd/qemu-nbd mounts. It did so in about one day of prompting. All xfstests pass across a variety of image settings, it supports backing images. I haven&#39;t touched a single line of code. I&#39;m really not sure how to feel about this 😔

Replies (5)

@lkundrak@metalhead.club 2026-03-23 08:17

@vegard the only way i can make sense of this is that now we can do the bongs and computers can do the thinking

Open ##1894126
@JohnAZoidberg@mastodon.online 2026-03-23 08:18

@vegard how confident are you that it's working "correctly"?

Open ##1894127
@etchedpixels@mastodon.social 2026-03-23 09:20

@vegard you spent a day 'prompting' it. So analogous to spending a day prompting a compiler. Don't see it as any difference except the source and error message process between the two in the sense both had a programming source input and both took time. In one case I imagine a tool figured out what code to borrow without checking licences and in the other a human looked at existing bits, aware of licences and pasted it together

Open ##1894131
@andyprice@mastodon.social 2026-03-23 09:55

@vegard Question is, where's the performance bug in nbd?

Open ##1894133
@penguin42@mastodon.org.uk 2026-03-23 12:28

@vegard I'd want to check that you're comparing the same caching and writeback settings and ordering semantics; in some of the more careful modes I know the qemu code is careful not to tell the guest a write is complete until it gets to.. the os? the disk? not sure - but that can be a source of some perf differences. Still if it's actually 10% faster, then finding out why would be interesting and telling @stefanha !

Open ##1894136