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

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

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: архитектура, особенности и отличия от других файловых систем

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

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, спасибо! На явные деградации в производительности сейчас уделяется большое внимание.

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

Я бы сказал, что у каждого решения своя специфика и нюансы.

Про тот же btrfs, хотя его автор и признавал, что вдохновлялся и ZFS (хоть и не сразу), но по архитектуре они весьма отличаются, плюс отличается также и логика управления массивом.

Универсального решения нет, у всех свои плюсы-минусы, но весомый аргумент в сторону ZFS тут обычно — это опыт промышленного использования, скоро будет 20 лет как он существует.

А вообще это тема для отдельного цикла статей :)

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

Ну, во-первых, это доп. функционал, который обеспечивает WAL, тут я ещё раз соглашусь.

А в рамках контекста статьи именно бэкап, point in time recovery в zfs иногда можно обеспечить за счёт снапшотов.

Т.е. я не хотел сказать, что WAL теперь вообще не нужен :) А что задачу целостности данных с него ZFS может забрать (как и некоторые другие).

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

Размениваться на скорость параллельной записи, против latency — такое себе.

Для требовательных к write latency нагрузок нужно использовать Slog.

Не говоря уже про заявления о том что на ZFS не нужен WAL.

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

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

Подскажите, Георгий. Учитывая текущее состояние разработки ZFS, для каких сценариев использования Вы бы рекомендовали ZFS. Или же пока лучше использовать в режиме Бета-теста?

OpenZFS является стабильным продуктом, особенно с учётом его упора на отказоустойчивость. В режиме бета-теста стоит использовать только альфа-релизы, стабильные версии можно смело использовать везде. Конечно же, это не отменяет надобности делать бекапы, как и на любой ФС.

Классические сценарии использования:
— локальная ФС (к примеру, я использую её как корневую ФС на всех своих инсталляциях)
— локальное файловое/блочное хранилище для масштабов, где сетевые ФС, такие как ceph, излишни (хороший пример — proxmox)
— Posix-совместимое локальное файловое хранилище, отлично подходит для классических хранилок на большое количество дисков

Для исключения нарушения целостности ZFS достаточно ли синхронной записи или же обязательно наличие ИБП?

ZFS на уровне файловой системы всегда обеспечивает целостность за счёт использования merkle tree и атомарности, т.е. даже отключив синхронную запись на датасете через sync=disabled, ФС после сбоя по питанию останется целой. Но это приведёт к откату на последнюю корректно записанную транзакцию.

Информация

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