oridb

This is what Google did for me before it got enshittified, but it did it efficiently and reliably.

Hiring someone else to find them is boring as hell. If you only care about being spoonfed results, I don't think there's much to talk about.

Well, sure, the same way that I can "cook" a three michelin star meal by going out to eat at the French Laundry.

It's just boring. And the people that crow about "their" accomplishments are tiresome.

It's done on 9front. The mechanical work of translating it to OpenBSD is not yet done.

I don't mean a literal trim command to the block device, but hints that get passed to the RAID layer to mark how blocks should be spread among the backing devices. I haven't put much thought into the details, but I suspect that there might not be so much information needed, so the RAID layer could be both generic and smart. It may not work out.

I'll probably be picking Allan's brain on a few things in the coming few months; amusingly, he mentioned doesn't use ZFS for ZFS development so that he can unload and reload the module, and he's interested in something that won't corrupt when he panics the kernel.

Qcow2 will zero blocks on power loss, at least in some configurations.

Author here: correct, it's currently on the user to deal with corrupted data. I'm not opposed to adding a RAID layer, but I also want to explore what adding trim-style feedback to a generic RAID layer may look like, so that different file systems could share the work.

We'll see where things go.