>> - How does bcachefs avoid the dreaded RAID write hole?
> We're copy on write - and this extends to our erasure coding
> implementation, we don't update existing stripes in place -
> we create new stripes as needed, reusing buckets from existing
> stripes that still have data.

То, что в бтрфс ниасилили (и видимо уже никогда ниасилят), но осилили в openZFS.

>> - How does an O_DIRECT loop device on bcachefs compare to a zvol on ZFS?
> I'd have to benchmark/profile it. It appears there's some bugs in the way the
> loop driver in O_DIRECT mode interacts with bcachefs according to xfstests, and
> the loopback driver is implemented in a more heavyweight way that it needs to be -
> there's room for improvement.

То есть для образов дисков для виртуалок оно непригодно, как и btrfs. btrfs если кто не в курсе. ужаснейшим образом фрагментируется с CoW образом диска и просто тормозит (в 2-3 раза медленее ext4) с no-CoW образом. Во втором случае ещё и остаётся без упаковки. в openZFS образы дисков в виде zdev просто ЛЕТАЮТ, быстрее чем голый диск работают. Не говоря уже о том, что упаковка на лету всегда имеется.

Про то чем лучше снапшоты так и не понял. в btrfs снапшоты просто замечательные, можно эн копий оси иметь например и грузиться по выбору в любую (пару раз пригождалось иметь новую и старую системы). В openZFS такое без доп ужимок и прыжков не выйдет (сначала надо снапшот сделать, потом его из снапшота преобразовать в полноценный датасет, а уж что делать чтоб забутиться из грёбанного initramfs в другой рут-датасет я даже не в курсе; в btrfs тупо в грубе выбирается аргументом ядру другой снапшот он же subvolume).