> Отсюда и размер

а теперь подумайте верхней головой - сколько при заполненном полутерабайте у хранилки получится abd чанков и как вы будете теперь искать среди них нужный, сколько займет индекс подобных чанков, и что происходит с блоком стандартных для zfs 128k при чтении, при записи, при обращениях?
Отдельно об эффективности дерганья alloc/free на каждые 4k когда они понадобились/не понадобились (следить за экспайром тоже будете отдельно, перебирая все блоки - как еще-то?).
Что линукс не умеет нормального управления памятью в ядре - не вопрос, зачем только было этот код делать не линуксонли? У разработчика, очевидно, нет тестовых и рабочих систем большого объема, поэтому ему в голову вообще не пришло подумать. Или никого в ней не застало и ушло.

У фри с ее zones этой проблемы, внезапно, нет.

Что страницы у вас 4k - совершенно необязательно означает, что хранить кэш диска надо блоками размером в страницу, а не размером в блок на диске, так, для разнообразия. Или даже в цепочку последовательных блоков, которую вернул prefetch - понадобится из середины, посчитаете смещение когда уже понадобилось - зато сам блок найдете в индексе в 64 раза меньшем.

Ну и на сладкое уже из самой freebsd - неумение kib@ и компании писать работающий код с первого раза, а не с пятнадцатого, если прямая копипаста невозможна. Почитайте комитлоги вокруг abd.c/h - просветлитесь. В том числе и их недоумению "а как это работает вообще".