Миф из вашей ссылки в том, что команда scrub «пересчитывает чексуммы ещё раз и может записать неправильные данные», а по факту scrub никогда не запишет новые данные с новой чексуммой. Всё просто:
— читаем данные и чексумму с диска
— если ОЗУ битая и они не сошлись — пытаемся при наличии другой копии этих данных вычитать их с другого диска
— если, и только если чексумма сойдётся с данными — scrub запишет эту копию вместо «битой» со старой. Но это будет та же чексумма и те же данные
— да, вероятность записи битых данных в таком случае есть, но она аналогична другим ФС. Но шансы сильно больше, что scrub не сможет посчитать чексумму со всех копий данных в пуле и просто переведёт пул в suspended, тем самым обезопасив вас.
— и даже если вам супер повезло и вы записали битые данные и чек сумму, при следующей вычитке проверка не пройдёт и вы об этом узнаете. А на ФС без чексумм вы будете по кругу неограниченное время работать с битыми данными и не знать этого.
Это всё с условием, что вам очень повезло и Ваша ОС работает продолжительное время с битой памятью.
Давно не лазил в эту часть мускуля, но думал, что он только вычитывает бинлоги. У перконы есть возможность читать только первый и последний бинлог если включить одну настройку. Вы же про бинлоги?
Вы правы про оверхед 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 остался.
Миф из вашей ссылки в том, что команда scrub «пересчитывает чексуммы ещё раз и может записать неправильные данные», а по факту scrub никогда не запишет новые данные с новой чексуммой. Всё просто:
— читаем данные и чексумму с диска
— если ОЗУ битая и они не сошлись — пытаемся при наличии другой копии этих данных вычитать их с другого диска
— если, и только если чексумма сойдётся с данными — scrub запишет эту копию вместо «битой» со старой. Но это будет та же чексумма и те же данные
— да, вероятность записи битых данных в таком случае есть, но она аналогична другим ФС. Но шансы сильно больше, что scrub не сможет посчитать чексумму со всех копий данных в пуле и просто переведёт пул в suspended, тем самым обезопасив вас.
— и даже если вам супер повезло и вы записали битые данные и чек сумму, при следующей вычитке проверка не пройдёт и вы об этом узнаете. А на ФС без чексумм вы будете по кругу неограниченное время работать с битыми данными и не знать этого.
Это всё с условием, что вам очень повезло и Ваша ОС работает продолжительное время с битой памятью.
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 остался.