https://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSRecordsizeAndCompression
Про это я знал, но действительно теперь убедился воочию. Экономить байты
в record-е нельзя -- можно экономить только количество секторов
занимаемых на жёстком диске. Если мы хотим сжать 8 KiB record, то при
сжатии его до 5 KiB, мы ровным счётом ничего не выиграем, ибо оно
всё-равно на ashift=12 будет занимать два сектора на диске. Но если у
нас маленький размер сектора (512 байт, ashift=9), то сэкономим
несколько секторов и именно сжатое представление будет записано на
диске, действительно экономя.
При увеличении размера record-а, мы конечно уже будем иметь больше
шансов на экономию блоков. Однако небольшие record-ы часты при
использовании zvol-ов и различных СУБД.
Плюс, большой ashift ещё может означать большой расход места в пустую
при большом количестве маленьких файлов. В ZFS нет такой штуки как
субаллокация блоков, когда в одном блоке диска содержатся данные
нескольких файлов. Возможно имеет смысл делать меньший ashift даже для
4K дисков ради экономии места.
А также нельзя забывать про то, что нулевые блоки не будут записываться
на диск *ТОЛЬКО* если включена компрессия. Поэтому, если у вас zvol с
4-8 KiB recordsize, а компрессия не сжимает лучше чем в два раза, то
всё-равно имеет смысл её включать (хотя бы zle) чтобы срабатывал триггер
на экономию полностью нулевых блоков.
А ещё помнить про то, что если оно всё запускается поверх GELI
зашифрованного диска, то не забывать в этом GELI указывать тоже
соответствующий размер сектора: это сэкономит затраты на полнодисковое
шифрование, так как для каждого сектора вектора инициализации
рассчитываются отдельно, а секторов тут будет в восемь раз меньше
затрагиваться.