https://opennet.ru/openforum/vsluhforumID3/117164.html Крис Мур (Kris Moore), создатель проекта PC-BSD и вице-президент компании iXsystems, объявил (https://lists.freebsd.org/pipermail/freebsd-current/2019-April/073176.html) о начале тестирования установочных сборок FreeBSD 12-STABLE (https://pkg.trueos.org/iso/freebsd12-zol/) и FreeBSD 13-HEAD (https://pkg.trueos.org/iso/freebsd13-zol/), в которых изначально поддерживаемая во FreeBSD реализация файловой системы ZFS заменена на наработки проекта "ZFS on Linux (https://zfsonlinux.org/)". Благодаря инициативе по обеспечению переносимости кода "ZFS on Linux" на другие системы, для FreeBSD были подготовлены (https://github.com/zfsonfreebsd/ZoF) порты sysutils/zol (утилиты) и sysutils/zol-kmod (модуль ядра), которые теперь предлагается протестировать. В контексте файловой системы, наиболее простым способом тестирования является предоставление готовых установочных образов, в которых изначальная реализация ZFS отключена и предустановлены порты с "ZFS on Linux". В качестве ФС для корневого раздела могут использоваться U https://opennet.ru/openforum/vsluhforumID3/117164.html#235 Tue, 18 Jun 2019 06:03:11 GMT &gt;Мы проверяли,<br>&gt;на отдельный быстрый NVMe-диск,<br>&gt;улучшение записи<br><br>Как http://www.databasesoup.com/2015/02/running-with-scissors-mode.html проверяли?...<br> https://opennet.ru/openforum/vsluhforumID3/117164.html#234 Mon, 17 Jun 2019 11:35:02 GMT &gt; (!) Ни один из перечисленных не предоставляет опцию "подпереть очередь записи на устройство".<br><br>Я хочу дополнить коллегу Шигорина следующими соображениями:<br><br>Мы проверяли, ZIL именно это и делает. Если выносить SLOG на отдельный быстрый NVMe-диск, то разница в записи получается разительная. Я точные цифры тех наших изысканий не нашёл, но там где-то в 5-6 раз улучшение записи, емнип.<br><br>Также, помнится, 28го декабря прошлого года Чистяков в Dell EMC делал доклад по идемпотентному описанию архитектуры, где среди прочего упоминал в частности и эту тему тоже.<br> https://opennet.ru/openforum/vsluhforumID3/117164.html#231 Mon, 10 Jun 2019 07:20:38 GMT Как типичный железняк думает только тот кто считает что кроме x86 ничего больше нет. А ПОХ весьма разносторонне думает. И FreeBSD писалась не только для x86 поэтому использует правильные методы для Операционной Системы и ее архитектуры, а не железа на которой она крутиться. <br> https://opennet.ru/openforum/vsluhforumID3/117164.html#230 Tue, 14 May 2019 06:18:28 GMT Коллега прокомментировал так: "в ZFS есть intent log (ZIL SLOG)".<br> https://opennet.ru/openforum/vsluhforumID3/117164.html#229 Mon, 13 May 2019 12:35:58 GMT &gt;&gt; Мне вот, например, нужно "подпирать" запись на медленные шпиндели <br>&gt;&gt; быстрыми ssd. И как это в linux сделать?<br>&gt; bcache?<br><br> Не поленился найти более-менее актуальный дайджест: https://habr.com/ru/company/first/blog/330040/<br>* bcache &#8212; отказать, т.к. скремблирует данные (посему ставится только в пару с пустым разделом) и в случае неисправности я не знаю что делать.<br>* lvm cache &#8212; afair, было только чтение. (Новый модуль от RH тоже дизайнили то ли программисты, то ли наркоманы. Им не накрыть VG, а на тестах я не увидел "вымывавания" кэша. Совсем. Засим попрощался.)<br>* flashcache &#8212; на локалхосте как-то работает. Игрался у себя на рабочей станции (openSUSE 42.1 на тот момент afair). Подпёр тогдашнее md-зеркало с xfs ≈2TB. Заподозрил потерю (мета)данных при включении write-back. (+ Модуль вгружался через раз из-за гонок, но тут уже&#769; моя лень править.)<br><br>(!) Ни один из перечисленных не предоставляет опцию "подпереть очередь записи на устройство". Что, как мне кажется, наиболее прямой п https://opennet.ru/openforum/vsluhforumID3/117164.html#228 Mon, 13 May 2019 10:38:58 GMT &gt; Мне вот, например, нужно "подпирать" запись на медленные шпиндели<br>&gt; быстрыми ssd. И как это в linux сделать?<br><br>bcache?<br> https://opennet.ru/openforum/vsluhforumID3/117164.html#227 Mon, 13 May 2019 08:52:34 GMT &gt; Не предусматривает в том плане, что выключение дедупа не ведёт к уменьшению <br>&gt; потребления рамы. Что было дедуплицировано, то останется таковым.<br><br> Хм. В моей картине мира ОЗУ отжирается в попытке держать все хэши "под рукой". Для этой самой дедупликации (нашёл одинаковый хэш &#8212; вставь ссылку на имеющийся блок /и с вероятностью ≈10^39 для SHA256 это таки верно/). При чтении оно отличается от случая "все блоки уникальные" только более компактным расположением данных. Постепенно рассасывающимся в процессе CoW. Я неправ?<br><br>&gt;&gt;&gt; Базы будете размещать, имейте в виду, что&#8230; <br>&gt;&gt; Не надо этого делать. CoW + CoW = fail.<br>&gt; Вот за это -- спасибо.<br><br> На всякий случай, аргументированное противоположное мнение<br>https://www.opennet.ru/openforum/vsluhforumID3/117278.html#88<br> Как всегда, нужно смотреть на условия применения. В описанном случае правильно спроектированный кэш в zfs даёт выигрыш больше, чем проигрыш от применения CoW.<br>* На обратной стороне dm-cache в linux, написанный какими-то хипстерами. М https://opennet.ru/openforum/vsluhforumID3/117164.html#226 Fri, 10 May 2019 23:40:27 GMT &gt;&gt; Никогда не включайте дедупликацию. Она требует добавления в систему порядка 20гигов рамы на терабайт диска, и не предусматривает пути назад.<br>&gt; Это с чего бы не предусматривает? Но таки да, включать есть смысл <br>&gt; разве что "на поиграться".<br><br>Не предусматривает в том плане, что выключение дедупа не ведёт к уменьшению потребления рамы. Что было дедуплицировано, то останется таковым.<br><br>&gt;&gt; Базы будете размещать, имейте в виду, что&#8230; <br>&gt; Не надо этого делать. CoW + CoW = fail.<br><br>Вот за это -- спасибо.<br><br>&gt;&gt; По поводу root-on-zfs <br>&gt; Плохая идея вне солярки. Разве что для развлечения. Если хотите иметь профит, <br>&gt; старайтесь обходить проблемные места.<br><br>А почему бы, собственно, и нет? zfs-снапшоты системы это всё-таки довольно удобно.<br><br>&gt;&gt; raidz <br>&gt; Не иначе как продавцы "полок" разработчикам занесли. Нужно было серьёзно постараться, чтобы <br>&gt; алгоритмически зафиксировать скорость не только записи, но и *чтения* с raidz. <br><br>А можно подробности? Я не имел времени разобраться, почему zfs увеличивает латент https://opennet.ru/openforum/vsluhforumID3/117164.html#225 Sun, 05 May 2019 05:10:48 GMT Посмотри тесты на фороникс<br><br>https://www.phoronix.com/scan.php?page=article&item=freebsd-zol-april<br>