> А заодно - гормально вписывающуюся в существующее ядро, а не дублирующее половину
> фукциональности.

ну вот вам и сделали...ой, ну то есть - "пишуть!"
на пехепе(ой, тоись, пихоне) + rust, чем вы недовольны-то? Ждите, ждите, будет вам "вписывающееся в существующее ведро" и "со всеми фичами zfs" - только вот на самом деле - "в том виде, в котором авторы сумели их понять, ни разу не имея опыта работы с оной - исключительно на бумаге, и из того списка, который реализован хотя бы наполовину в существующем ведре".
Они уже даже написали три интерфейса к dbus (отсюда, кстати, пихон). Вам не кажется, что начали немножко не с того? ;-)

Весь смысл zfs именно в том, что ту функциональность из ядра как раз и надо выкинуть и похоронить (хорошо бы - вместе с дбасом) - она во-первых, изначально плохо сделана и еще хуже развита (lvm), во-вторых, все это придумывали во времена дисков по 300мегабайт и оперативной памяти по 16, и в-третьих, если отдать управление именно файловой системе, которая работает со своими записями, а не с "блоками" фиксированной длинны, получается просто эффективнее.
Минус ровно один - это большая работа. Очень большая - посмотрите сколько лет прошло между работающей и надежной ext2 и гуглевым анонсом о переходе на ext4 (в крайне странной позе). То есть сколько лет решали гораздо более простую задачу.
Такое смогла сделать sun (потратив лет семь, помнится), потому что это была в общем-то хорошая и небедная лавка, в которую шли хорошие программисты, сотнями. А те, кого засасывает в оракл, либо сбегают оттуда через год, либо превращаются в унылых офисных рабов. Ну а у suse/not-well и прочих просто нет и никогда не будет денег нанять нужное количество. В итоге код btrfs пишут полтора инвалида, причем больше пары лет никто с ней копаться не остается, а это для такого проекта - ни о чем.