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

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

Отправить сообщение
Ну так 70% серверного рынка и не Windows…
А вот однозначный ответ core разработчика и создателя ZFS news.ycombinator.com/item?id=18480016, решайте сами кому верить.

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

Это всё с условием, что вам очень повезло и Ваша ОС работает продолжительное время с битой памятью.

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 остался.

Информация

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