Какой правильный вариант для Samba «строгое выделение» при обслуживании тома zfs?
Это логическое значение, управляющее распределением дискового пространства на сервере. Если для этого параметра установлено значение «Да», сервер изменит поведение UNIX, не фиксируя блоки реального дискового хранилища, когда файл расширяется, на поведение Windows, фактически заставляя дисковую систему выделять реальные блоки хранилища, когда файл создается или расширяется, чтобы быть данный размер. В терминологии UNIX это означает, что Samba перестанет создавать разреженные файлы.
Этот параметр действительно разработан для файловых систем, которые поддерживают быстрое выделение большого количества блоков, например файловых систем на основе экстентов. В файловых системах, которые не поддерживают экстенты (особенно ext3), это может замедлить работу Samba. Когда вы работаете с большими файлами
100 МБ в файловых системах без экстентов, вы можете даже столкнуться с проблемами с клиентами, у которых истекло время ожидания.
Когда у вас есть файловая система на основе экстентов, вполне вероятно, что мы сможем использовать незаписанные экстенты, которые позволяют Samba очень быстро выделять даже большие объемы пространства, и вы не увидите никаких проблем с тайм-аутом, вызванных строгим распределением. Если вы используете строгое выделение, вам также будет намного легче выводить сообщения о квотах, если вы используете квоты. Еще одно преимущество активации этого параметра заключается в том, что он помогает уменьшить фрагментацию файлов.
Чтобы дать вам представление о том, в каких файловых системах этот параметр может вам подойти в настоящее время: XFS, ext4, btrfs, ocfs2 в Linux и JFS2 в AIX поддерживают незаписанные экстенты. В файловых системах, которые его не поддерживают, предварительное выделение, вероятно, является дорогостоящей операцией, при которой вы увидите снижение производительности и риск возникновения таймаутов у клиентов при создании больших файлов. Примерами являются ext3, ZFS, HFS + и большинство других, поэтому имейте в виду, если вы активируете этот параметр в этих файловых системах.
По умолчанию: strict allocate = no
Итак, если у меня есть strict allocate = yes, Samba не выполняет предварительное выделение, что не дает преимущества в производительности ZFS?
С участием strict allocate = yes, Самба воля заранее выделить место. Поскольку ZFS не имеет распределения на основе экстентов, на странице руководства говорится, что это медленнее, чем strict_allocate = no.
Вы можете подумать, что если вы заранее скажете fs выделить все пространство для вашего огромного файла, то вероятность того, что это пространство будет непрерывным, выше, чем если бы вы выделяли его по частям; однако я не уверен, что это будет иметь место с zfs, который стремится сделать запись всех данных последовательной. Это определенно не будет иметь место, если у вас включено сжатие, потому что предварительно выделенное пространство будет пустым и будет сжиматься до одного блока, поэтому вы ничего не получите, включив strict_allocate.
FWIW, пробовал использовать fallocate -x для создания файла размером 10 ГБ на сжатом экземпляре ZFS потребовалось 2 минуты, что, вероятно, слишком долго для клиента CIFS. strace вывод показывает, что распределение выполнено с использованием нескольких миллионов pwrite64() звонки. Настоящий fallocate() звонок не поддерживается:
fallocate(3, 0, 0, 10000000000) = -1 EOPNOTSUPP (Operation not supported)
Это с относительно недавним мастером git zfsonlinux.
Основываясь на вышесказанном, я бы сказал, что было бы бесполезно и сильно мешало бы включать strict_allocate в сжатой файловой системе; для несжатых файлов с отключенной дедупликацией это, вероятно, только сильно мешает, но не обязательно бесполезно.