Как стать автором
Обновить
66
-1
Георгий Меликов @gmelikov

Пользователь

Отправить сообщение

Zfs тут ничем не отличается, для любой ФС ecc память предпочтительней.

ссылка t.me/sds_ru/15724 увы не открывается

Цитирую сам себя:
можно выставить xattr=sa, atime=off, recordsize=1M

Подробности описывал на русском тут в конце habr.com/ru/post/314506
— (промахнулся)
Давно не лазил в эту часть мускуля, но думал, что он только вычитывает бинлоги. У перконы есть возможность читать только первый и последний бинлог если включить одну настройку. Вы же про бинлоги?
Вы правы про оверхед ZFS на каждый блок, но я имел в виду тесты на данных именно про оверхед чтения всех 128к для получения 8-16к из них, и аналогично read-modify-write такого блока. Если запись-чтение происходит очень малыми блоками и не последовательно, то этот оверхед может быть больше, чем вы сэкономили в zfs на большом блоке.

L2arc — выгрузка редко используемого кеша l1arc (в озу) на диск.


Slog — запись zil (журнала синхронной записи до формирования txg) на отдельный быстрый носитель. Если он вам не нужен и вы готовы потерять синхронную запись за последние секунды — просто поставьте sync=disabled на датасет.


В обоих случаях выгружать их в рамдиск бессмысленно. Странная статья, признаться, в этой части.

Во всех на базе zfs и btrfs.


А по серьёзному — zfs для больших хранилок и делался. Nexenta, nutanix files, oracle zfssa, это только из головы.


Не скажу за опыты автора, но с большим количеством файлов она справляется лучше других фс. Для примера на тестах zfs хранит мету о файлах минимум в 2 раза эффективнее по месту, чем ext4.

Разве FLUSH TABLES WITH READ LOCK; в mysql не хватает для консистентных снапшотов, зачем его полностью тушить?

Размер блока оптимальный по производительности оказался 128кб,

зависит от данных в бд, стоит тестить


Zil slog можно не делать, достаточно прописать для датасета zfs асинхроную запись всегда и режим throughput.

Только если готовы потерять последние секунды записи, на кластерах может быть больно.


Добавлю ещё, что на линуксе, если вам не нужна 100%-ная совместимость пула с другими ОС, стоит выставлять xattr=sa, будет экономия нескольких iops на каждое изменение и чтение метаданных файлов.

Их позиция "нам пофиг на всё, что не в ядре" имеет право на жизнь, жаль что при этом начинаются политические игрища по поводу лицензий, при этом никто не агитирует gkh и Линуса вливать код zfs в ядро. Но зачем осознанно портить жизнь другим людям?


Но вот такой патч упорядочиванием кода назвать сложно, по сути убран экспорт функции для nongpl консьюмеров, и всё https://github.com/torvalds/linux/commit/12209993e98c5fa1855c467f22a24e3d5b8be205


Что мешало оставить экспорт как было раньше? Вот и недовольство.

Не знаю что имел в виду оригинальный автор, но Oracle ZFS storage appliance (ZFS SA) базируется на Solaris и там не OpenZFS.
Да, проблему решили, 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

Уже.
BSD: Уже 12+ лет имеет надёжную работающую ZFS реализацию.

Linux: До сих пор production ready ZFS нет.


А теперь барабанная дробь — BSD переезжает на кодовую базу ZFSonLinux, который теперь 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 — инструмент. В зависимости от целей он будет по разному использоваться. Почему вы пытаетесь притянуть ему желаемую в определённом продукте вами цель?
Давайте ещё раз — CoW магическим образом вам не даёт, к примеру, дедупликацию и снапшоты. Но, добавив ингредиенты (на примере ZFS — та же DDT), вы можете добиться нужной цели.

В ядре Линукса CoW был придуман именно для экономии оперативной памяти для переменных процессов при fork().

Не в ядре линука был придуман ни CoW, ни fork. https://en.wikipedia.org/wiki/Fork_(system_call) см. там же virtual memory в SunOS-4.0 от 1988 года.

По-моему — это исторически первая работающая реализация CoW.

Увы, но это не так, см. выше.
И всё-таки основная задача CoW — это экономия места. Из Википедии:

Вы вырвали из контекста как-то :) По умолчанию в CoW нет общих копий. Другой вопрос, что т.к. блок данных никогда не переписывается, позволяет его не удалять и использовать в других целях. Но это больше бонус, нежели цель.

И я вас расстрою — CoW всегда будет требовать больше пространства, чем классический подход. При заполнении более 90% любая CoW-like ФС начинает сильно деградировать по записи, т.к. свободное место дико фрагментировано и поиск свободного места нужного размера становится очень дорог. Да, это пытаются нивелировать всякими плюшками типа компрессии. Но это не основная цель CoW!

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Работает в
Зарегистрирован
Активность