Нет никаких требований "Х ОЗУ на ТБ", это тот же кеш, как и в любой другой ФС. Хотите держать больше кеша - увеличиваете его. В памяти нужна только мета - отдайте ей гигабайт 10 хоть на 10 петабайт и всё.
Хотите экономить и страдать на любой ФС - задушите её по памяти, в ZFS никто вам этого не мешает сделать.
Увы, и не в одном месте, "глобальные снимки" в том же openzfs, с его "устаревшим и ужасным дизайном", уже есть пару лет, как и вынос метаданных на отдельные диски.
Открываешь и читаешь исходники нужного куска системы/ПО. Берёшь любой уже написанный модуль ядра и делаешь из его исходников что угодно. Часто код самодокументируемый.
Про поведение проприетарных продуктов, не соответствующих документации, боюсь вспоминать.
Было бы полезно все-таки скидывать содержимое 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 в БД может использоваться, к примеру, и для репликации на другие инстансы. Этот момент я тоже в статье попытался рассказать.
Нет никаких требований "Х ОЗУ на ТБ", это тот же кеш, как и в любой другой ФС. Хотите держать больше кеша - увеличиваете его. В памяти нужна только мета - отдайте ей гигабайт 10 хоть на 10 петабайт и всё.
Хотите экономить и страдать на любой ФС - задушите её по памяти, в ZFS никто вам этого не мешает сделать.
Увы, и не в одном месте, "глобальные снимки" в том же openzfs, с его "устаревшим и ужасным дизайном", уже есть пару лет, как и вынос метаданных на отдельные диски.
Про поведение проприетарных продуктов, не соответствующих документации, боюсь вспоминать.
Смотря с какой стороны смотреть :)
дубль коммента, первых раз промахнулся с постом :(Хранение мелких блоков эффективнее на 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 в БД может использоваться, к примеру, и для репликации на другие инстансы. Этот момент я тоже в статье попытался рассказать.