ZFS – включить или отключить кеш диска?

Я настраиваю ZFS (через FreeNAS) с RAIDZ1 на сервере с 4 x WD Red SATA HDD (подключено через PERC H330 в режиме HBA).

Сервер подключен к ИБП.

Для ZFS и в данной конфигурации имеет ли смысл включить кеш-диск каждого жесткого диска, или это очень опасно, несмотря на ИБП?

Вы определенно должны включить кеш-диска.

Логика в том, что ZFS предполагает включенный кеш-диска и таким образом сбрасывает любые критические записи (то есть синхронные записи и переписывание uberblock) через соответствующие и специфические команды SATA/SAS (ATA FLUSH, FUA и т.д.).

Оставление включенного кеша дисков позволяет использовать возможность объединения записей современных дисков без влияния на надежность пула.

Это, конечно, предполагает, что ваши диски действительно выполняют команду сброса кеша, что является нормой для современных (после 2006 года) дисков. В редких случаях, когда ваши диски лгут о сбросе кеша, тогда вы должны отключить его.

В качестве дополнительной информации я предлагаю вам прочитать описание настройки zfs_nocacheflush:

ZFS использует барьеры (волатильные команды сброса кеша) для обеспечения записи данных на постоянные носители устройствами. Это обеспечивает консистентное состояние данных на носителях для устройств, где кеши волатильны (например, HDD).

Вы можете, если хотите. Это не принесет значительных изменений.
ZFS использует часть ОЗУ для кеша записей и периодически сбрасывает данные на диск.

С 4 дисками это похоже на небольшую установку, так что проведите тестирование обоих вариантов и посмотрите, есть ли вообще заметное преимущество.

Я склонен согласиться, но моя конфигурация может быть не оптимальной.
Мой пул:

zdata                           2.82T   822G     73    412  40.0M  46.1M                         raidz1-0                      2.82T   822G     73    412  40.0M  46.1M                           wwn-0x50014ee0019b83a6          -      -     16    106  10.0M  11.5M                           wwn-0x50014ee2b3f6d328          -      -     20    102  10.0M  11.5M                           wwn-0x50014ee25ea101ef          -      -     18    105  10.0M  11.5M                           wwn-0x50014ee057084591          -      -     16     97  9.94M  11.5M                       logs                                -      -      -      -      -      -                         wwn-0x50000f0056424431-part5   132K   112M      0      0      0      0                       cache                               -      -      -      -      -      -                         wwn-0x50000f0056424431-part4  30.7G   270M      0      5  2.45K   517K                       ------------------------------  -----  -----  -----  -----  -----  -----

Обоснование. Это выделенный NAS на основе ОС arch с контроллером Promise SATA2. Поскольку на Samsung SSD с arch еще оставалось достаточно места, я решил использовать его в качестве журнала и устройства кеша и добавить в пул ZFS. Учитывая, что Promise является только PCI устройством, я ожидал повышения производительности за счет журнала и кеша на SSD. В повседневном использовании я не вижу увеличения производительности.

Для увеличения случайных операций записи (IOPS), мы должны включить невvolatile кеш записи (вращающийся диск).
Эта функция требует поддержки программного обеспечения, например: ZFS, а не для ext4 или XFS.
В ZFS на Linux/Solaris/FreeBSD сообщество ZFS рекомендует прямое подключение по SAS/SATA или SCSI-сети (SAS/волоконный канал) через IO-расширитель.
Адаптер аппаратного RAID по умолчанию отключает весь кеш записи в режиме RAID, и он может работать в режиме JBOD для всех устройств и включать невvolatile кеш записи.

В Linux прямое подключение устройства будет показывать эти логи, это зависит от микропрограммы устройства SAS/SATA от производителя устройства.

[sdc] Write cache: enabled, read cache: enabled, supports DPO and FUA
or
[sdcl] Write cache: enabled, read cache: disabled, supports DPO and FUA

writeback_cache_control.txt

но это означает, что операционная
система должна принудительно выталкивать данные на невvolatile хранилище, когда она выполняет
операцию сохранности данных, как fsync, sync или размонтирование

Принудительный доступ к устройству
-----------------

Флаг REQ_FUA может быть добавлен к r/w флагам биозаписи, отправленной от
файловой системы и будет гарантировать завершение I/O запросов только после 
записи данных на невvolatile хранилище.

вот документ Linux в blk-flush.c

 * Если устройство имеет кеш записи с возвращением и поддерживает FUA, 
 * REQ_PREFLUSH переводится в PREFLUSH, но REQ_FUA передается напрямую с данными.
 *
 * Если устройство имеет кеш записи с возвращением и не поддерживает FUA, 
 * REQ_PREFLUSH переводится в PREFLUSH и REQ_FUA переводится в POSTFLUSH.

до кода Linux 4.7

/**
 * blk_queue_flush - настройка возможности сброса кеша очереди
 * @q: очередь запросов для устройства
 * @flush: 0, REQ_FLUSH или REQ_FLUSH | REQ_FUA
 *
 * Сообщает блочному слою о возможности сброса кеша @q. Если поддерживается
 * сброс, то должен быть установлен REQ_FLUSH. Если поддерживается обход
 * кеша записи для отдельных записей, то должен быть установлен REQ_FUA.
 */
void blk_queue_flush(struct request_queue *q, unsigned int flush)
{
        WARN_ON_ONCE(flush & ~(REQ_FLUSH | REQ_FUA));

        if (WARN_ON_ONCE(!(flush & REQ_FLUSH) && (flush & REQ_FUA)))
                flush &= ~REQ_FUA;

        q->flush_flags = flush & (REQ_FLUSH | REQ_FUA);
}

После linux 4.7

/**
 * blk_queue_write_cache - настройка кеша записи очереди
 * @q: очередь запросов для устройства
 * @wc: кеш записи с обратным сохранением включен или выключен
 * @fua: устройство поддерживает FUA записи, если true
 *
 * Сообщает блочному слою о кеше записи @q.
 */
void blk_queue_write_cache(struct request_queue *q, bool wc, bool fua)
{
        if (wc)
                blk_queue_flag_set(QUEUE_FLAG_WC, q);
        else
                blk_queue_flag_clear(QUEUE_FLAG_WC, q);
        if (fua)
                blk_queue_flag_set(QUEUE_FLAG_FUA, q);
        else
                blk_queue_flag_clear(QUEUE_FLAG_FUA, q);

        wbt_set_write_cache(q, test_bit(QUEUE_FLAG_WC, &q->queue_flags));
}
EXPORT_SYMBOL_GPL(blk_queue_write_cache);

Openzfs на linux данных сброса

/*
 * 4.7 API,
 * Интерфейс blk_queue_write_cache() заменил интерфейс blk_queue_flush()
 * Однако, новый интерфейс только для GPL, поэтому мы реализуем
 * собственный тривиальный обертку, если обнаружен вариант только для GPL.
 *
 * 2.6.36 - 4.6 API,
 * Интерфейс blk_queue_flush() заменил интерфейс blk_queue_ordered()
 * Однако, в то время как старый интерфейс был доступен всем,
 * новый - только для GPL. Таким образом, если обнаружена версия только
 * для GPL, мы реализуем собственный тривиальный помощник.
 */

Программное обеспечение выглядит достаточно.
Если какая-то ошибка в аппаратном обеспечении (черный ящик), программное обеспечение не сможет это остановить.

Удачи и сделайте резервное копирование всех важных данных.