Давно не лазил в эту часть мускуля, но думал, что он только вычитывает бинлоги. У перконы есть возможность читать только первый и последний бинлог если включить одну настройку. Вы же про бинлоги?
Вы правы про оверхед ZFS на каждый блок, но я имел в виду тесты на данных именно про оверхед чтения всех 128к для получения 8-16к из них, и аналогично read-modify-write такого блока. Если запись-чтение происходит очень малыми блоками и не последовательно, то этот оверхед может быть больше, чем вы сэкономили в zfs на большом блоке.
L2arc — выгрузка редко используемого кеша l1arc (в озу) на диск.
Slog — запись zil (журнала синхронной записи до формирования txg) на отдельный быстрый носитель. Если он вам не нужен и вы готовы потерять синхронную запись за последние секунды — просто поставьте sync=disabled на датасет.
В обоих случаях выгружать их в рамдиск бессмысленно. Странная статья, признаться, в этой части.
А по серьёзному — zfs для больших хранилок и делался. Nexenta, nutanix files, oracle zfssa, это только из головы.
Не скажу за опыты автора, но с большим количеством файлов она справляется лучше других фс. Для примера на тестах zfs хранит мету о файлах минимум в 2 раза эффективнее по месту, чем ext4.
Размер блока оптимальный по производительности оказался 128кб,
зависит от данных в бд, стоит тестить
Zil slog можно не делать, достаточно прописать для датасета zfs асинхроную запись всегда и режим throughput.
Только если готовы потерять последние секунды записи, на кластерах может быть больно.
Добавлю ещё, что на линуксе, если вам не нужна 100%-ная совместимость пула с другими ОС, стоит выставлять xattr=sa, будет экономия нескольких iops на каждое изменение и чтение метаданных файлов.
Их позиция "нам пофиг на всё, что не в ядре" имеет право на жизнь, жаль что при этом начинаются политические игрища по поводу лицензий, при этом никто не агитирует gkh и Линуса вливать код zfs в ядро. Но зачем осознанно портить жизнь другим людям?
Да, проблему решили, GKH принял патч, где несколько функций начали экспортировать только для GPL совместимых модулей. Пришлось сделать патч и реализовать просто часть логики на стороне zfsonlinux.
Т.е. мейнтейнеры ядра придерживаются подхода «на всё, что не в ядре — нам плевать» и они не пытаются помогать сторонним проектам, а иногда (не буду говорить насколько осознанно) вставляют этим палки в колёса. Но всё можно обойти на своей стороне.
что за примерно год прошедший с начала объявления процесса миграции разработка ZFS во FreeBSD фактически заморожена и она получила из кодовой базы наработанной в рамках ZoL примерно ничего
Именно.
ZoL, наконец-то, получила SSD TRIM
С другой реализацией с нуля, если что.
и ZFS on root.
Вы серьёзно? Я 5 лет этим на линуксе пользуюсь уже, и я не первый.
Не понимаю что вы хотите доказать. FreeBSD будет собираться из репы ZoL->OpenZFS? Да. «разработка ZFS во FreeBSD фактически заморожена». Вот и переезд на кодовую базу. Вас смущает терминология?
Если хотите что-то объяснить, то скажите просто что вам в этом выражении не нравится.
Нет никакой «кодовой базы ZoL», а есть репозиторий где на базе OpenZFS пилили
Ну это и есть кодовая база проекта ZoL. Речь именно о жизни в конкретном репозитории, до этого все OpenZFS проекты жили отдельно, теперь непосредственно в репу ZoL добавляют обвязки для сборки из неё и для FreeBSD.
Чем вам «кодовая база» не нравится?:)
Было принято решение о слиянии базовых репозиториев, где велась разработка ZFS для различных систем на базе ZoL потому что он более жив, чем использовавшийся ранее аналогичный в проекте IllumOS.
Как непосредственно участвовавший — слияния репозиториев нет, ZoL активно пилит свои фичи и он уже 2-3 года впереди, мы давно забекпортили все нужные изменения из Illumos и уже несколько лет бекпортят из ZoL в обратную сторону. В том числе и «костыли», как вы их называете.
Репозиторий ZoL, кстати, на днях будет переименован в OpenZFS
задача, если смотреть глобально, одинаковая — «сделать быстро».
Обобщение очень похоже на кнопку «Сделать хорошо», уж извините за сравнение :)
с secondarycache=metadata l2arc решает задачу вымывания метаданных из кэша
Эм, не приходит в голову кейс, когда нужно так делать. Уж лучше наоборот — primarycache=metadata и secondarycache=all, класть на l2arc только мету — уж лучше её держать в ОЗУ, а L2ARC если уж есть, то отдать на всё остальное.
то становится понятным, что special allocation class — киллер-фича.
Согласен, только я не понял что вы хотели сказать, изначально ваш вопрос был, как я понял, «когда использовать l2arc а когда special vdev».
L2ARC скоро будет персистентным, его кейс чисто про кеширование чтения, и он с этим справляется отлично. Special vdev конечно дал новые возможности, но кейс для L2ARC остался.
Ну всё же задачи у них разные, как и требования к резервированию, special class диски персистентны и их обязательно нужно резервировать.
А l2arc лучше обычно заменить добавлением озу.
Касаемо issue — проблема сейчас только в том, что данные со special class vdevs тоже будут кешироваться в l2arc. Если вам очень нужны оба — это не так критично, т.к. Метаданных по сравнению с данными всё равно сильно меньше.
CoW — это инструмент. Он не даёт магическим образом всё, что вы пожелаете.
Цель у каждого продукта своя. CoW — инструмент. В зависимости от целей он будет по разному использоваться. Почему вы пытаетесь притянуть ему желаемую в определённом продукте вами цель?
Давайте ещё раз — CoW магическим образом вам не даёт, к примеру, дедупликацию и снапшоты. Но, добавив ингредиенты (на примере ZFS — та же DDT), вы можете добиться нужной цели.
В ядре Линукса CoW был придуман именно для экономии оперативной памяти для переменных процессов при fork().
И всё-таки основная задача CoW — это экономия места. Из Википедии:
Вы вырвали из контекста как-то :) По умолчанию в CoW нет общих копий. Другой вопрос, что т.к. блок данных никогда не переписывается, позволяет его не удалять и использовать в других целях. Но это больше бонус, нежели цель.
И я вас расстрою — CoW всегда будет требовать больше пространства, чем классический подход. При заполнении более 90% любая CoW-like ФС начинает сильно деградировать по записи, т.к. свободное место дико фрагментировано и поиск свободного места нужного размера становится очень дорог. Да, это пытаются нивелировать всякими плюшками типа компрессии. Но это не основная цель CoW!
Zfs тут ничем не отличается, для любой ФС ecc память предпочтительней.
Цитирую сам себя:
Подробности описывал на русском тут в конце habr.com/ru/post/314506
L2arc — выгрузка редко используемого кеша l1arc (в озу) на диск.
Slog — запись zil (журнала синхронной записи до формирования txg) на отдельный быстрый носитель. Если он вам не нужен и вы готовы потерять синхронную запись за последние секунды — просто поставьте sync=disabled на датасет.
В обоих случаях выгружать их в рамдиск бессмысленно. Странная статья, признаться, в этой части.
Во всех на базе zfs и btrfs.
А по серьёзному — zfs для больших хранилок и делался. Nexenta, nutanix files, oracle zfssa, это только из головы.
Не скажу за опыты автора, но с большим количеством файлов она справляется лучше других фс. Для примера на тестах zfs хранит мету о файлах минимум в 2 раза эффективнее по месту, чем ext4.
Разве
FLUSH TABLES WITH READ LOCK;
в mysql не хватает для консистентных снапшотов, зачем его полностью тушить?зависит от данных в бд, стоит тестить
Только если готовы потерять последние секунды записи, на кластерах может быть больно.
Добавлю ещё, что на линуксе, если вам не нужна 100%-ная совместимость пула с другими ОС, стоит выставлять xattr=sa, будет экономия нескольких iops на каждое изменение и чтение метаданных файлов.
Их позиция "нам пофиг на всё, что не в ядре" имеет право на жизнь, жаль что при этом начинаются политические игрища по поводу лицензий, при этом никто не агитирует gkh и Линуса вливать код zfs в ядро. Но зачем осознанно портить жизнь другим людям?
Но вот такой патч упорядочиванием кода назвать сложно, по сути убран экспорт функции для nongpl консьюмеров, и всё https://github.com/torvalds/linux/commit/12209993e98c5fa1855c467f22a24e3d5b8be205
Что мешало оставить экспорт как было раньше? Вот и недовольство.
Т.е. мейнтейнеры ядра придерживаются подхода «на всё, что не в ядре — нам плевать» и они не пытаются помогать сторонним проектам, а иногда (не буду говорить насколько осознанно) вставляют этим палки в колёса. Но всё можно обойти на своей стороне.
Именно.
С другой реализацией с нуля, если что.
Вы серьёзно? Я 5 лет этим на линуксе пользуюсь уже, и я не первый.
Не понимаю что вы хотите доказать. FreeBSD будет собираться из репы ZoL->OpenZFS? Да. «разработка ZFS во FreeBSD фактически заморожена». Вот и переезд на кодовую базу. Вас смущает терминология?
Если хотите что-то объяснить, то скажите просто что вам в этом выражении не нравится.
Ну это и есть кодовая база проекта ZoL. Речь именно о жизни в конкретном репозитории, до этого все OpenZFS проекты жили отдельно, теперь непосредственно в репу ZoL добавляют обвязки для сборки из неё и для FreeBSD.
Чем вам «кодовая база» не нравится?:)
Как непосредственно участвовавший — слияния репозиториев нет, ZoL активно пилит свои фичи и он уже 2-3 года впереди, мы давно забекпортили все нужные изменения из Illumos и уже несколько лет бекпортят из ZoL в обратную сторону. В том числе и «костыли», как вы их называете.
Уже.
А теперь барабанная дробь — BSD переезжает на кодовую базу ZFSonLinux, который теперь OpenZFS.
Обобщение очень похоже на кнопку «Сделать хорошо», уж извините за сравнение :)
Эм, не приходит в голову кейс, когда нужно так делать. Уж лучше наоборот — primarycache=metadata и secondarycache=all, класть на l2arc только мету — уж лучше её держать в ОЗУ, а L2ARC если уж есть, то отдать на всё остальное.
Согласен, только я не понял что вы хотели сказать, изначально ваш вопрос был, как я понял, «когда использовать l2arc а когда special vdev».
L2ARC скоро будет персистентным, его кейс чисто про кеширование чтения, и он с этим справляется отлично. Special vdev конечно дал новые возможности, но кейс для L2ARC остался.
Ну всё же задачи у них разные, как и требования к резервированию, special class диски персистентны и их обязательно нужно резервировать.
А l2arc лучше обычно заменить добавлением озу.
Касаемо issue — проблема сейчас только в том, что данные со special class vdevs тоже будут кешироваться в l2arc. Если вам очень нужны оба — это не так критично, т.к. Метаданных по сравнению с данными всё равно сильно меньше.
CoW — это инструмент. Он не даёт магическим образом всё, что вы пожелаете.
Цель у каждого продукта своя. CoW — инструмент. В зависимости от целей он будет по разному использоваться. Почему вы пытаетесь притянуть ему желаемую в определённом продукте вами цель?
Давайте ещё раз — CoW магическим образом вам не даёт, к примеру, дедупликацию и снапшоты. Но, добавив ингредиенты (на примере ZFS — та же DDT), вы можете добиться нужной цели.
Не в ядре линука был придуман ни CoW, ни fork. https://en.wikipedia.org/wiki/Fork_(system_call) см. там же virtual memory в SunOS-4.0 от 1988 года.
Увы, но это не так, см. выше.
Вы вырвали из контекста как-то :) По умолчанию в CoW нет общих копий. Другой вопрос, что т.к. блок данных никогда не переписывается, позволяет его не удалять и использовать в других целях. Но это больше бонус, нежели цель.
И я вас расстрою — CoW всегда будет требовать больше пространства, чем классический подход. При заполнении более 90% любая CoW-like ФС начинает сильно деградировать по записи, т.к. свободное место дико фрагментировано и поиск свободного места нужного размера становится очень дорог. Да, это пытаются нивелировать всякими плюшками типа компрессии. Но это не основная цель CoW!