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

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

Как не быть программистом, раскурить eBPF за сутки и начать мониторить DNS

dsc так и работает для целей сбора статистики https://github.com/DNS-OARC/dsc

Яндекс выложил в опенсорс YDB

Битвы на территории ZFS

Xfs на петабайты чудесным образом работает без кеша метаданных? И её мета из lru кеша не вымывается тем же чудом?

Расскажите, пожалуйста, как без озу держать петабайты и дышать полной грудью на какой-то ФС.

Битвы на территории ZFS

Нет никаких требований "Х ОЗУ на ТБ", это тот же кеш, как и в любой другой ФС. Хотите держать больше кеша - увеличиваете его. В памяти нужна только мета - отдайте ей гигабайт 10 хоть на 10 петабайт и всё.

Хотите экономить и страдать на любой ФС - задушите её по памяти, в ZFS никто вам этого не мешает сделать.

Второе интервью с разработчиком Reiser4 Эдуардом Шишкиным

Увы, и не в одном месте, "глобальные снимки" в том же openzfs, с его "устаревшим и ужасным дизайном", уже есть пару лет, как и вынос метаданных на отдельные диски.

5 причин, по которым я люблю программировать в Linux

Открываешь и читаешь исходники нужного куска системы/ПО. Берёшь любой уже написанный модуль ядра и делаешь из его исходников что угодно. Часто код самодокументируемый.

Про поведение проприетарных продуктов, не соответствующих документации, боюсь вспоминать.

Смотря с какой стороны смотреть :)

Анонимный Дед Мороз 2020-2021: пост хвастовства новогодними подарками

Спасибо, Дедушка, за необычный и оригинальный подарок! Это esp32 с нужной прошивкой и набором светодиодиков! Будет светомузыка и в нашем доме :)

image

Ещё фотки
image
image

дубль коммента, первых раз промахнулся с постом :(

Клуб анонимных Дедов Морозов 2020–2021 на Habr

Ох, вот промахнулся так промахнулся :(

Клуб анонимных Дедов Морозов 2020–2021 на Habr

Спасибо, Дедушка, за необычный и оригинальный подарок! Это esp32 с нужной прошивкой и набором светодиодиков! Будет светомузыка и в нашем доме :)

image

Ещё фотки
image
image

ZFS: архитектура, особенности и отличия от других файловых систем

Было бы полезно все-таки скидывать содержимое special на обычные vdev в простое, все-таки special не для расширения пула создают, а для производительности

Хранение мелких блоков эффективнее на mirror, чем на raidz, special vdev создавался в первую очередь для эффективного и производительного хранения мелких блоков в пулах с raidz/draid. Плюс не стоит забывать, что в настоящий момент в ZFS нет механизма автоматической модификации данных без явной перезаписи (т.н. block pointer rewrite), т.е. схемы «сделать что-то потом с данными» в ZFS сейчас в принципе нет.

Да и у схем с «скидывать в простое» тоже есть свои минусы, это доп. нагрузка, тоже не универсальная штука. Ну и резервировать такие диски тоже нужно, смысл от пула, часть данных которого потеряна на «промежуточном» этапе.

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

Если был отказ дисков, то тут мало что поможет. Схема с «скидывать в простое» привела бы к такому же итогу, вы не можете уменьшать избыточность, не увеличивая риск отказа (касаемо каких-либо буферов на запись). Схема с slog работает только по причине того, что эти же данные сразу приедут на vdevs в виде асинхронной записи. И то, если данные важны, то slog тоже нужно резервировать.

Данные в какой-то момент всё равно должны быть записаны с резервированием, если вы не хотите гарантировать отказоустойчивость special vdev, то ваша идея отличается от классического использования slog только моментом сброса на hdd vdevs данных.

А для кеша на чтение уже сделали персистентный l2arc.

ZFS: архитектура, особенности и отличия от других файловых систем

Special vdev в первую очередь является самым обычным vdev, только с определёнными приоритетами на запись. Все vdevs в пуле равны по критичности потери. Однако, если special vdev использовался с самого начала, то при его потере даже используя механизмы, позволяющие импортировать пул без одного vdev ( openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Module%20Parameters.html#zfs-max-missing-tvds ) смысла в этом будет мало, т.к. все метаданные будут потеряны (хотя тут стоит протестировать объём доступного к восстановлению, у меня не доходили руки).

Если вы хотите разделять данные по степени отказоустойчивости, то сейчас штатно это делается только через создание разных пулов.

ZFS: архитектура, особенности и отличия от других файловых систем

Что это? Как я понимаю, preallocation в принципе в CoW не возможен — не прав? И на примере — пусть Transmission пишет файл, кусками в случайном порядке. На не CoW ФС preallocation как раз эту проблему и решает. А как у нас теперь?

Подробности описаны в PR github.com/openzfs/zfs/pull/10408, поддержка preallocation на ZFS не пишет блоки на диск, но проверяет, что места на пуле для записи файла данного размера хватит.
Основная причина реализации таких вещей — приложения при отсутствии возможности воспользоваться preallocation могут попытаться выполнить бессмысленную на CoW FS работу, например писать превентивно нули, что бессмысленно.

2) Redacted zfs send/receive

Тут стоит посмотреть на примеры и описание из man openzfs.github.io/openzfs-docs/man/8/zfs-redact.8.html
Кратко по памяти — создаётся клон от нужного снапшота, в нём чистится sensitive информация, и итоговый send поток заменяет соответствующие блоки на пометку REDACT. На принимающей стороне из такого неполноценного снапшота можно создать рабочий клон.

ZFS: архитектура, особенности и отличия от других файловых систем

да, массив будет гораздо меньшее время в degraded state, но ИМХО в случае raidz2 (и тем более z3) это не так уж важно, зато общее время ребилда («всё тормозит») увеличится.

Когда в пуле больше 100 дисков, то сокращение времени в degraded state всё же критично.

в raidz нельзя добавить диск.

Сейчас — да, но в скором времени будет можно github.com/openzfs/zfs/pull/8853

в случае raidz же максимальный рекомендуемый размер записи — 1 мегабайт

Можно задавать размер блока до 16М, увеличив параметр модуля zfs_max_recordsize. Оно прекрасно работает (проверено не раз лично), но только для соответствующего профиля, т.к. операции с таким размером блока сильно уменьшают iops (относится и к обычному raid).

фича «special vdev» очень крута, конечно, но есть впечатление, что дизайнили второпях.
нельзя реализовать многоуровневое хранилище,

В момент разработки данного функционала у vdevs не было своих свойств (properties). Как они будут реализованы — на их основе можно будет сделать такую приоритизацию.

ZFS: архитектура, особенности и отличия от других файловых систем

Нужно выставить special_small_blocks=1M

ZFS: архитектура, особенности и отличия от других файловых систем

Ошибка записи по свободному месту, после очистки пул продолжит работу.

ZFS: архитектура, особенности и отличия от других файловых систем

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

Под каждую задачу свой инструмент, идеального решения нет. В статье я указал только ситуацию в конкретном подразделении конкретной компании, и то в рамках дозволенного к оглашению :). Если говорить только обо мне, то за рамками остались остальные личные/рабочие инсталляции с ZFS, которые здравствуют и бесшовно обновляются уже который год, переживая сбои и некорректную работу дисков, ОЗУ, ЦПУ, блоков питания и т.д.
Это я ещё не перечислил продукты других компаний с ZFS, существующие не первый год.

зы вообще столкнулся с тем, что нет стабильной ФС со сжатием под линь. А надо: очень экономит место на небольших VDS.
ззы вечные беты btrfs, reiser4(5), zfs не предлагать!

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

ZFS: архитектура, особенности и отличия от других файловых систем

Т.н. rule of thumb тут выглядит по другому — использовать raidz только для блоков размером не менее, к примеру, 32К. Для сглаживания этой проблемы реализовали special allocation class, на миррор из ссд можно вынести все мелкие блоки, (и метадату, и, при желании, все блоки с recordsize меньше определённого размера).

Т.е. можно собрать пул на raidz со special vdev, оставить дефолтный recordsize=128k, выставить special_small_blocks=32K, и все маленькие файлы или файлы с мелким блоком (recordsize до 32К) будут эффективно записываться на ssd mirror, а большие файлы — на raidz hdd.

В целом можно сказать, что raidz стоит использовать в основном для эффективного хранения данных с большим размером блока. В остальных случаях нужно считать оверхед по iops/используемому пространству.

ZFS: архитектура, особенности и отличия от других файловых систем

Моё субъективное мнение — да, ZFS прекрасно подходит для нужд холодного хранения данных. В частности, продукты ProxMox отлично интегрированы с ним и имеют хорошую документацию на этот счёт pbs.proxmox.com/docs/sysadmin.html

ZFS: архитектура, особенности и отличия от других файловых систем

Про конкретно эту таблицу не скажу, а для расчёта эффективной утилизации пространства в RAIDZ актуальна аналогичная таблица из статьи www.delphix.com/blog/delphix-engineering/zfs-raidz-stripe-width-or-how-i-learned-stop-worrying-and-love-raidz, если вы спрашиваете в этом контексте. Надо будет мне добавить эту табличку в документацию.

ZFS: архитектура, особенности и отличия от других файловых систем

Если у вас есть порядок воспроизведения данных проблем при большом количестве файлов с ZFS — будем рады данной информации, по возможности пришлите в issue tracker github.com/openzfs/zfs/issues, спасибо! На явные деградации в производительности сейчас уделяется большое внимание.

Информация

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