на какой странице?
лучше весь. но можно:
2. Barebone setup 8Core Xeon, 32GB Ram - Single HD vs SSD vs NVMe vs Optane - Dual HD vs SSD vs NVMe vs Optane
- Quad HD vs SSD vs NVMe vs Optane - ramcache enabled vs disabled
2.13 single Optane 800P pool vs Single 900P
2.14 Dual Optane 800P pool vs Dual 900P
3. Sync write with different Slog - ZeusRAM, P3600/ 3700
and Optane Slog (32G vs 800P/900P) - onpool ZIL vs dedicated Slog
3.3 Diskbased pool + Optane 32G Slog 3.5 Diskbased pool + Optane 900P Slog
3.10 16x SSD pool + Optane 800P Slog
3.11 16x SSD pool + Optane 900P Slog
3.12 16x SSD pool + multiple Slog
3.13 11x HD pool + single Slog partition
3.14 same but two/three Slog partitions
Сергей
Fedor
Проблема в том, что данные можно потерять даже при записи в zil, если на этом диске нет конденсатора, да и то, что не успеет попасть в кэш диска всё равно пропадёт.
Вопрос вообще использовать механизм кэширования записи при ссд пуле и насколько я понимаю, этот процес построения блока для записи вообще не возможно выключить, т.к это часть zfs и в памятью оно все равно будет писать.
Другое дело, энергонезависимая память.
Хотя с третьей стороны, ибп который тушит сервер при критическом заряде.
Во всех остальных случаях выход из строя аппаратных частей приведёт к невозможности записи транзакций которые небыли сброшены, зил лишь сведёт их количество к минимуму.
Или я не прав?
из зила, если нет батарейки, пропадут данные.
но, исходя из:
зфс точно знает, что было записано (почему NCQ это плохо).
Fedor
если кеш в зиле будет жив, и NCQ будет отключен, то всё будет хорошо
Fedor
Как говорил Георгий, в коде написано, что если используется весь диск, то кеши на дисках отключаются.
Евгений
из зила, если нет батарейки, пропадут данные.
но, исходя из:
зфс точно знает, что было записано (почему NCQ это плохо).
Я про то, что всё равно требуется время на запись даже в зил.
Fedor
время требуется. но такая запись жёстко синхронизирована, обёрнута в транзакцию.
Fedor
если получилось записать - транзакция закрывается.
Евгений
В любом случа часть транзакций потеряется
Fedor
не получилось - при восстановлении будет использоваться предыдущая
Fedor
так что целостность будет всегда.
Fedor
а вот сколько секунд новых данных потеряются - это уже все транзактные системы этому подвержены.
Евгений
а вот сколько секунд новых данных потеряются - это уже все транзактные системы этому подвержены.
Кроме случаев, когда система ждёт подтверждения записи
Fedor
если она не получила подтверждения - транзакция не закрывается.
Fedor
и механизм CoW прекрасно оставит предыдущее содержимое этого блока.
Fedor
при восстановлении будет использована транзакция, где этот блок ещё со старым содержимым
Fedor
предыдущая, короче
Олег
на это пофиг+- вопрос в другом какой дистриб ставить
Олег
)))
Fedor
у меня омниос - нашёл багу. так что не могу его столь яро рекомендовать теперь.
Евгений
и механизм CoW прекрасно оставит предыдущее содержимое этого блока.
Я не про то, если мы используем all flash pool и не используем zil ( отключаем его) процесс записывающий блок данных будет ждать подтверждения записи и получит его только после того, как данные запишутся в основной пул, на сколько этот кейс будет медленней
Fedor
бага в STMF
Fedor
Я не про то, если мы используем all flash pool и не используем zil ( отключаем его) процесс записывающий блок данных будет ждать подтверждения записи и получит его только после того, как данные запишутся в основной пул, на сколько этот кейс будет медленней
сначала то что летело в зил улетит в основной пул. это будет дольше, остальной механизм - как описано выше
Fedor
но в случае если пул - ссд, то не сильно дольше.
Евгений
Кстати спорный момент про зеркало для zil
Fedor
если зил улетит - улетит весь пул
Fedor
если у зила будет миррор - миррор вытащит пул
Евгений
Ибп потушит сервак раньше чем питание вырубят
Fedor
я не про это. например, аппаратный дефект в зил, из за которого он просто сдох
Fedor
или в RO перешел
Сергей
Я не про то, если мы используем all flash pool и не используем zil ( отключаем его) процесс записывающий блок данных будет ждать подтверждения записи и получит его только после того, как данные запишутся в основной пул, на сколько этот кейс будет медленней
отключаем zil это sync=disabled? жёстко вы))
Евгений
если у зила будет миррор - миррор вытащит пул
В остальных вариантах копия zil в памяти всегда есть
Fedor
в памяти в основном не зил а арк
Fedor
и если зил у вас улетит - так и так пул будет остановлен, несмотря на то, что в памяти что-то есть
Евгений
Да нет же, zil это bbu
Fedor
нет, зил это аналог лога предзаписи
Сергей
Зато надёжно :))
ZIL - ZFS Intent Log (лог намерений ZFS)
Используется во время операций синхронной записи. ZIL является неотъемлемой частью файловой системы и не рекомендуется его отключать. При отключенном режиме достигается значительный прирост производительности, однако это может привести к нарушению целостности данных ( !!! ), поскольку ZFS будет игнорировать требования синхронизации транзакций таких приложений, как Базы Данных и NFS.
Евгений
Fedor
чот меня смущает то, что тут написано
Сергей
https://sites.google.com/site/luzanov/freebsd/zfs/zfs_tuning
Сергей
А ну перепутал, я имел ввиду синхронную запись
синхронную запись наоборот не нужно отключать, если для вас критична сохранность данных. Если важна и хотите при этом получить приемлемую скорость - выносите ZIL на отдельное устройство (оно и будет SLOG).
Fedor
ZIL - ZFS Intent Log (лог намерений ZFS)
Используется во время операций синхронной записи. ZIL является неотъемлемой частью файловой системы и не рекомендуется его отключать. При отключенном режиме достигается значительный прирост производительности, однако это может привести к нарушению целостности данных ( !!! ), поскольку ZFS будет игнорировать требования синхронизации транзакций таких приложений, как Базы Данных и NFS.
If the write eventually fails, or the system suffers a crash or fault preventing its writing, then ZFS can identify all the writes that it has confirmed were written, by reading back the SLOG (the only time it is read from), and use this to completely repair the data loss.
Евгений
Один хрен оно сначала в память потом дамп на диск ( выделенный zil или в pool) кидает
Fedor
If the log device itself is lost, it is possible to lose the latest writes, therefore the log device should be mirrored. In earlier versions of ZFS, loss of the log device could result in loss of the entire zpool, although this is no longer the case. Therefore, one should upgrade ZFS if planning to use a separate log device.
Fedor
оказвыается, теперь не всегда пул теряется)
Fedor
пропустил этот момент
Евгений
Когда уже память с батарейками в массы дадут :))
Fedor
есть же
Fedor
такие мощности сейчас особо не нужны
Евгений
Тот же zil уже не нужен будет
Fedor
ну так оптанов поставить нвме - и не будет нужно
Fedor
наиболее близкое и бюджетное решение
Fedor
какой максимальный размер у них кстати?
Евгений
Только в массовом использовании этого нет и в по не реализована функция - у меня память с батарейкой, юзаем её а не внешний накопитель
Fedor
а те штуки по 2, 4тб?
Fedor
кстати, тмфпс + рамдиск - можете потестировать :D
Евгений
зависит от скорости подачи ио на запись
:))) а у тебя пул должен переваривать не меньше.
Там же есть ограничение по времени хранения перед сбросом в пул
Олег
так какой дистриб) ответа так и нет)
Fedor
:))) а у тебя пул должен переваривать не меньше.
Там же есть ограничение по времени хранения перед сбросом в пул
Оно будет вставать в очередь :)
Евгений
Оно будет вставать в очередь :)
Очередь лимитирована по времени, в доке написано было, что пул на чтение будет стопить, что бы записать
Олег
Fedor
Будет :)
Евгений
Поэтому раздувать zil нет смысла
Fedor
Именно. Но слишком мелким его делать тоже не стоит.
Евгений
Отложенной записи в 5 минут не будет :)
Fedor
Капитаним, сэр 😁
Евгений
Fedor
Кстати, я тут один на омниос?)