Какой правильный вариант для «строгого выделения» Samba при обслуживании тома zfs?
Какой правильный вариант для Samba «строгое выделение» при обслуживании тома zfs?
Это логическое значение, которое управляет обработкой выделения дискового пространства s «строгое выделение» при обслуживании тома zfs? Какой правильный вариант для «строгого выделения» Samba при обслуживании тома zfs? В документации говорится: Это логическое значение, которое управляет распределением дискового пространства на сервере. ...
Какой правильный вариант для Samba «строгое выделение» при обслуживании тома zfs?
Это логическое значение, которое управляет обработкой выделения дискового пространства s «строгое выделение» при обслуживании тома zfs? Какой правильный вариант для «строгого выделения» Samba при обслуживании тома zfs? В документации говорится: Это логическое значение, которое управляет распределением дискового пространства на сервере. ...
Какой правильный вариант для 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 Samba будет предварительно выделить пространство. Поскольку 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 (Операция не поддерживается)
Это с относительно недавним мастером zfsonlinux git .
На основании вышеизложенного я бы сказал, что было бы бесполезно и сильно нарушать работу включения strict_allocate в сжатой файловой системе; для несжатых файлов с отключенной дедупликацией это, вероятно, только сильно мешает работе, но не обязательно бесполезно.