Открываешь и читаешь исходники нужного куска системы/ПО. Берёшь любой уже написанный модуль ядра и делаешь из его исходников что угодно. Часто код самодокументируемый.
Про поведение проприетарных продуктов, не соответствующих документации, боюсь вспоминать.
Было бы полезно все-таки скидывать содержимое 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.
Special vdev в первую очередь является самым обычным vdev, только с определёнными приоритетами на запись. Все vdevs в пуле равны по критичности потери. Однако, если special vdev использовался с самого начала, то при его потере даже используя механизмы, позволяющие импортировать пул без одного vdev ( openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Module%20Parameters.html#zfs-max-missing-tvds ) смысла в этом будет мало, т.к. все метаданные будут потеряны (хотя тут стоит протестировать объём доступного к восстановлению, у меня не доходили руки).
Если вы хотите разделять данные по степени отказоустойчивости, то сейчас штатно это делается только через создание разных пулов.
Что это? Как я понимаю, 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. На принимающей стороне из такого неполноценного снапшота можно создать рабочий клон.
да, массив будет гораздо меньшее время в degraded state, но ИМХО в случае raidz2 (и тем более z3) это не так уж важно, зато общее время ребилда («всё тормозит») увеличится.
Когда в пуле больше 100 дисков, то сокращение времени в degraded state всё же критично.
в случае raidz же максимальный рекомендуемый размер записи — 1 мегабайт
Можно задавать размер блока до 16М, увеличив параметр модуля zfs_max_recordsize. Оно прекрасно работает (проверено не раз лично), но только для соответствующего профиля, т.к. операции с таким размером блока сильно уменьшают iops (относится и к обычному raid).
фича «special vdev» очень крута, конечно, но есть впечатление, что дизайнили второпях.
нельзя реализовать многоуровневое хранилище,
В момент разработки данного функционала у vdevs не было своих свойств (properties). Как они будут реализованы — на их основе можно будет сделать такую приоритизацию.
И сразу противоречие! И оно как то незримо фоном идет во всех статьях про эту ФС. Прокомментируйте, почему так сложилось хотя бы у Вас.
Под каждую задачу свой инструмент, идеального решения нет. В статье я указал только ситуацию в конкретном подразделении конкретной компании, и то в рамках дозволенного к оглашению :). Если говорить только обо мне, то за рамками остались остальные личные/рабочие инсталляции с ZFS, которые здравствуют и бесшовно обновляются уже который год, переживая сбои и некорректную работу дисков, ОЗУ, ЦПУ, блоков питания и т.д.
Это я ещё не перечислил продукты других компаний с ZFS, существующие не первый год.
зы вообще столкнулся с тем, что нет стабильной ФС со сжатием под линь. А надо: очень экономит место на небольших VDS.
ззы вечные беты btrfs, reiser4(5), 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 прекрасно подходит для нужд холодного хранения данных. В частности, продукты ProxMox отлично интегрированы с ним и имеют хорошую документацию на этот счёт pbs.proxmox.com/docs/sysadmin.html
Если у вас есть порядок воспроизведения данных проблем при большом количестве файлов с ZFS — будем рады данной информации, по возможности пришлите в issue tracker github.com/openzfs/zfs/issues, спасибо! На явные деградации в производительности сейчас уделяется большое внимание.
Я бы сказал, что у каждого решения своя специфика и нюансы.
Про тот же btrfs, хотя его автор и признавал, что вдохновлялся и ZFS (хоть и не сразу), но по архитектуре они весьма отличаются, плюс отличается также и логика управления массивом.
Универсального решения нет, у всех свои плюсы-минусы, но весомый аргумент в сторону ZFS тут обычно — это опыт промышленного использования, скоро будет 20 лет как он существует.
Размениваться на скорость параллельной записи, против latency — такое себе.
Для требовательных к write latency нагрузок нужно использовать Slog.
Не говоря уже про заявления о том что на ZFS не нужен WAL.
С точки зрения целостности он и правда не нужен, если правильно настроить размер блока записи и делать сброс данных на диск в нужный момент. Другой вопрос, что WAL в БД может использоваться, к примеру, и для репликации на другие инстансы. Этот момент я тоже в статье попытался рассказать.
Подскажите, Георгий. Учитывая текущее состояние разработки ZFS, для каких сценариев использования Вы бы рекомендовали ZFS. Или же пока лучше использовать в режиме Бета-теста?
OpenZFS является стабильным продуктом, особенно с учётом его упора на отказоустойчивость. В режиме бета-теста стоит использовать только альфа-релизы, стабильные версии можно смело использовать везде. Конечно же, это не отменяет надобности делать бекапы, как и на любой ФС.
Классические сценарии использования:
— локальная ФС (к примеру, я использую её как корневую ФС на всех своих инсталляциях)
— локальное файловое/блочное хранилище для масштабов, где сетевые ФС, такие как ceph, излишни (хороший пример — proxmox)
— Posix-совместимое локальное файловое хранилище, отлично подходит для классических хранилок на большое количество дисков
Для исключения нарушения целостности ZFS достаточно ли синхронной записи или же обязательно наличие ИБП?
ZFS на уровне файловой системы всегда обеспечивает целостность за счёт использования merkle tree и атомарности, т.е. даже отключив синхронную запись на датасете через sync=disabled, ФС после сбоя по питанию останется целой. Но это приведёт к откату на последнюю корректно записанную транзакцию.
Про поведение проприетарных продуктов, не соответствующих документации, боюсь вспоминать.
Смотря с какой стороны смотреть :)
дубль коммента, первых раз промахнулся с постом :(Хранение мелких блоков эффективнее на mirror, чем на raidz, special vdev создавался в первую очередь для эффективного и производительного хранения мелких блоков в пулах с raidz/draid. Плюс не стоит забывать, что в настоящий момент в ZFS нет механизма автоматической модификации данных без явной перезаписи (т.н. block pointer rewrite), т.е. схемы «сделать что-то потом с данными» в ZFS сейчас в принципе нет.
Да и у схем с «скидывать в простое» тоже есть свои минусы, это доп. нагрузка, тоже не универсальная штука. Ну и резервировать такие диски тоже нужно, смысл от пула, часть данных которого потеряна на «промежуточном» этапе.
Если был отказ дисков, то тут мало что поможет. Схема с «скидывать в простое» привела бы к такому же итогу, вы не можете уменьшать избыточность, не увеличивая риск отказа (касаемо каких-либо буферов на запись). Схема с slog работает только по причине того, что эти же данные сразу приедут на vdevs в виде асинхронной записи. И то, если данные важны, то slog тоже нужно резервировать.
Данные в какой-то момент всё равно должны быть записаны с резервированием, если вы не хотите гарантировать отказоустойчивость special vdev, то ваша идея отличается от классического использования slog только моментом сброса на hdd vdevs данных.
А для кеша на чтение уже сделали персистентный l2arc.
Если вы хотите разделять данные по степени отказоустойчивости, то сейчас штатно это делается только через создание разных пулов.
Подробности описаны в PR github.com/openzfs/zfs/pull/10408, поддержка preallocation на ZFS не пишет блоки на диск, но проверяет, что места на пуле для записи файла данного размера хватит.
Основная причина реализации таких вещей — приложения при отсутствии возможности воспользоваться preallocation могут попытаться выполнить бессмысленную на CoW FS работу, например писать превентивно нули, что бессмысленно.
Тут стоит посмотреть на примеры и описание из man openzfs.github.io/openzfs-docs/man/8/zfs-redact.8.html
Кратко по памяти — создаётся клон от нужного снапшота, в нём чистится sensitive информация, и итоговый send поток заменяет соответствующие блоки на пометку REDACT. На принимающей стороне из такого неполноценного снапшота можно создать рабочий клон.
Когда в пуле больше 100 дисков, то сокращение времени в degraded state всё же критично.
Сейчас — да, но в скором времени будет можно github.com/openzfs/zfs/pull/8853
Можно задавать размер блока до 16М, увеличив параметр модуля
zfs_max_recordsize. Оно прекрасно работает (проверено не раз лично), но только для соответствующего профиля, т.к. операции с таким размером блока сильно уменьшают iops (относится и к обычному raid).В момент разработки данного функционала у vdevs не было своих свойств (properties). Как они будут реализованы — на их основе можно будет сделать такую приоритизацию.
special_small_blocks=1MПод каждую задачу свой инструмент, идеального решения нет. В статье я указал только ситуацию в конкретном подразделении конкретной компании, и то в рамках дозволенного к оглашению :). Если говорить только обо мне, то за рамками остались остальные личные/рабочие инсталляции с ZFS, которые здравствуют и бесшовно обновляются уже который год, переживая сбои и некорректную работу дисков, ОЗУ, ЦПУ, блоков питания и т.д.
Это я ещё не перечислил продукты других компаний с ZFS, существующие не первый год.
Критерий стабильности каждый определяет для себя сам, как и выбор инструмента для конкретных задач.
Т.е. можно собрать пул на raidz со special vdev, оставить дефолтный recordsize=128k, выставить special_small_blocks=32K, и все маленькие файлы или файлы с мелким блоком (recordsize до 32К) будут эффективно записываться на ssd mirror, а большие файлы — на raidz hdd.
В целом можно сказать, что raidz стоит использовать в основном для эффективного хранения данных с большим размером блока. В остальных случаях нужно считать оверхед по iops/используемому пространству.
Про тот же btrfs, хотя его автор и признавал, что вдохновлялся и ZFS (хоть и не сразу), но по архитектуре они весьма отличаются, плюс отличается также и логика управления массивом.
Универсального решения нет, у всех свои плюсы-минусы, но весомый аргумент в сторону ZFS тут обычно — это опыт промышленного использования, скоро будет 20 лет как он существует.
А вообще это тема для отдельного цикла статей :)
А в рамках контекста статьи именно
бэкап, point in time recoveryв zfs иногда можно обеспечить за счёт снапшотов.Т.е. я не хотел сказать, что WAL теперь вообще не нужен :) А что задачу целостности данных с него ZFS может забрать (как и некоторые другие).
Для требовательных к write latency нагрузок нужно использовать Slog.
С точки зрения целостности он и правда не нужен, если правильно настроить размер блока записи и делать сброс данных на диск в нужный момент. Другой вопрос, что WAL в БД может использоваться, к примеру, и для репликации на другие инстансы. Этот момент я тоже в статье попытался рассказать.
OpenZFS является стабильным продуктом, особенно с учётом его упора на отказоустойчивость. В режиме бета-теста стоит использовать только альфа-релизы, стабильные версии можно смело использовать везде. Конечно же, это не отменяет надобности делать бекапы, как и на любой ФС.
Классические сценарии использования:
— локальная ФС (к примеру, я использую её как корневую ФС на всех своих инсталляциях)
— локальное файловое/блочное хранилище для масштабов, где сетевые ФС, такие как ceph, излишни (хороший пример — proxmox)
— Posix-совместимое локальное файловое хранилище, отлично подходит для классических хранилок на большое количество дисков
ZFS на уровне файловой системы всегда обеспечивает целостность за счёт использования merkle tree и атомарности, т.е. даже отключив синхронную запись на датасете через
sync=disabled, ФС после сбоя по питанию останется целой. Но это приведёт к откату на последнюю корректно записанную транзакцию.ufo привет!