Потому что ZFS происходит из Solaris, и там 8K был стандартом, поэтому всё было построено вокруг этого. И ZFS хранит несколько копий метаданных, поэтому уменьшение размера блока сделает соотношение данных к метаданным ещё хуже. Ты можешь сделать это сам, используя CLI, например, командой zfs set recordsize=1M rpool/data. Все LXC будут наследовать этот recordsize. Но размер recordsize обычно не так важен, так как это не фиксированное значение. Это просто верхний предел, и ZFS сам решает, какого размера использовать запись. В Windows есть размер кластера, который можно определить при форматировании раздела, например, с помощью NTFS. Он будет группировать сектора до размера кластера. Так что да, было бы лучше форматировать NTFS с размером кластера, соответствующим твоему volblocksize. Немного раздражает, что графический интерфейс установщика Windows не позволяет определить размер кластера, поэтому новая Windows будет установлена с размером 4K, если ты не отформатируешь диски вручную во время установки.

Не обязательно, что это будет работать лучше. Допустим, при использовании `default ashift=12` и `redundant_metadata=all` для каждой записи выполняется 2 записи метаданных в формате 4K. При выполнении одной 8K записи будет храниться 1x 8K данных + 2x 4K метаданных (= всего 16K). Если выполнять 2 записи по 4K, то будет храниться 2x 4K данных + 4x 4K метаданных (= всего 24K). Значит, если слишком сильно уменьшать `volblocksize`, то накладные расходы на метаданные станут очень большими.

"zpool iostat -r" - это не совсем верный подход, потому что он не учитывает IOP и накладные расходы метаданных самого ZFS, из-за чего обновление каждого блока размером менее 64 кБ примерно обходится одинаково. Я тестировал файловые системы виртуальных машин на базе ZFS уже 10 дней (с OpenSolaris), и volblocksize или recordsize в 64 кБ всегда стабильно показывал себя как оптимальный вариант. При этом потребление памяти увеличивается несущественно. Большинство файловых систем используют экстенты, поэтому наихудший сценарий взрывного потребления памяти из-за мелких обновлений по множеству произвольных блоков в 64 кБ практически никогда не случается.