задача, если смотреть глобально, одинаковая — «сделать быстро».
Обобщение очень похоже на кнопку «Сделать хорошо», уж извините за сравнение :)
с secondarycache=metadata l2arc решает задачу вымывания метаданных из кэша
Эм, не приходит в голову кейс, когда нужно так делать. Уж лучше наоборот — primarycache=metadata и secondarycache=all, класть на l2arc только мету — уж лучше её держать в ОЗУ, а L2ARC если уж есть, то отдать на всё остальное.
то становится понятным, что special allocation class — киллер-фича.
Согласен, только я не понял что вы хотели сказать, изначально ваш вопрос был, как я понял, «когда использовать l2arc а когда special vdev».
L2ARC скоро будет персистентным, его кейс чисто про кеширование чтения, и он с этим справляется отлично. Special vdev конечно дал новые возможности, но кейс для L2ARC остался.
Ну всё же задачи у них разные, как и требования к резервированию, special class диски персистентны и их обязательно нужно резервировать.
А l2arc лучше обычно заменить добавлением озу.
Касаемо issue — проблема сейчас только в том, что данные со special class vdevs тоже будут кешироваться в l2arc. Если вам очень нужны оба — это не так критично, т.к. Метаданных по сравнению с данными всё равно сильно меньше.
CoW — это инструмент. Он не даёт магическим образом всё, что вы пожелаете.
Цель у каждого продукта своя. CoW — инструмент. В зависимости от целей он будет по разному использоваться. Почему вы пытаетесь притянуть ему желаемую в определённом продукте вами цель?
Давайте ещё раз — CoW магическим образом вам не даёт, к примеру, дедупликацию и снапшоты. Но, добавив ингредиенты (на примере ZFS — та же DDT), вы можете добиться нужной цели.
В ядре Линукса CoW был придуман именно для экономии оперативной памяти для переменных процессов при fork().
И всё-таки основная задача CoW — это экономия места. Из Википедии:
Вы вырвали из контекста как-то :) По умолчанию в CoW нет общих копий. Другой вопрос, что т.к. блок данных никогда не переписывается, позволяет его не удалять и использовать в других целях. Но это больше бонус, нежели цель.
И я вас расстрою — CoW всегда будет требовать больше пространства, чем классический подход. При заполнении более 90% любая CoW-like ФС начинает сильно деградировать по записи, т.к. свободное место дико фрагментировано и поиск свободного места нужного размера становится очень дорог. Да, это пытаются нивелировать всякими плюшками типа компрессии. Но это не основная цель CoW!
DDT в случае ZFS — это та самая таблица, которая хранит информацию о дедуплицированных данных (dedup table). Вот тут как раз и кроется проблема и dedup и возможного reflink — если хочется делать всё это онлайн, а не когда нибудь потом, то для записи (и изменения данных) вам придётся по всей этой таблице ходить (а вы хотите это сделать онлайн, иначе смысла в reflink при наличии штатной дедупликации нет). Т.е. держать её в памяти. Т.е. по грубым расчётам 20ГБ ОЗУ на 1ТБ диска. Иначе — привет запись 400КБ/сек и ниже.
Это пример из конкретной реализации ZFS и причины, почему дедупликацию в ней НЕ рекомендуют включать. Конечно стоит добавить, что именно эту ситуацию тоже пытаются улучшить github.com/zfsonlinux/zfs/issues/405#issuecomment-57201194, но в этой презентации явно показана стоимость дедупликации. Кратко — она всё равно не бесплатна.
А, ну и если вам очень хочется reflink в ZFS — просто включите дедупликацию :) Даже cp менять не придётся. Только включать дедупликацию я не рекомендую, если ваш коэффициент дедупликации меньше 20, см. требования к ОЗУ выше. Лучше онлайн lz4 компрессию использовать.
Если найдёте тесты на доступ к reflinked файлам, близкие к реальным кейсам — было бы интересно на них посмотреть, спасибо!
Во-первых это не юзерский сценарий. Масса пакетов и программ делают это автоматически без ведома юзера.
IIRC не всё так радужно, было бы отлично найти реальные тесты работы ПО с включенным reflink, окромя ручного копирования. Часто файлы при работе лежат либо в tmpfs, либо на других ФС, и reflink тут не поможет. А просто так делать cp туда-сюда в рамках одной ФС — ну, такое.
Важный момент — тесты должны проверят скорость дальнейшей работы с reflinked файлами, иначе самое интересное вы как раз таки выкидываете за борт :) Вы в статье критикуете именно аргумент про производительность при изменении reflinked файла («Also for performance reasons you may want the writes to happen at copy time rather than some latency sensitive process working on a CoW file and being delayed by the writes possibly to a different part of a mechanical disk.»), а тесты именно на это не делаете.
А во-вторых в случае reflink дедупликация даётся бесплатно.
Работа с дедуплицированными данными не всегда бесплатна.
На мой взгляд reflink без CoW невозможен. В основе снимков лежит тот же механизм, что и у reflink.
Так и при чём тут CoW ФС, приследовавшие совершенно другие цели, как ранее уже сказал Enchant? Чисто технически можно и на ext4 сделать нашлёпку для reflink. Да, механизм будет похож на CoW, но блин, это не магические 3 буквы :)
Рассматривая ваше сравнение reflink со снапшотами — да, механизм похож, но это не значит, что в ФС со снапшотами вы автоматом получаете reflinks. На примере ZFS — всё есть дерево, при создании снапшота грубо говоря создаётся родительский блок, наследующий все предыдущие состояния датасета, и не позволяющий их удалять. Но снапшот здесь per-dataset. Reflink же требует не просто похожий механизм, но на уровне отдельного файла, но и ещё должен давать адекватную скорость при доступе к блокам reflinked файлов. Это же тоже не бесплатно, плюс выбивается из архитектуры данной ФС. Т.е. в ZFS снапшоты бесплатны именно на создание. Но удаление снапшотов — не бесплатно. То же самое, только хуже, будет и для reflink, где удаление будет происходить сильно чаще.
И, в случае ZFS, reflinks должны полагаться на DDT, а не на снапшоты github.com/zfsonlinux/zfs/issues/405#issuecomment-57201194
Ну я вам про конкретные в комментарии вашем — дедупликация та же, она далеко не бесплатна.
Так же и с аргументами про reflink — вы сами соглашаетесь с первым его аргументом. И, касаемо reflink — это нарушение стандартного поведения, не без последствий. А их без веской причины вообще менять не любят.
Вы приводите аргументы за 1 конкретный юзерский сценарий «быстро копировать файлы». В то время, как другие сценарии могут быть сильно весомее. И тут я согласен по поводу того, что при смене поведения сильно пострадают сценарии, рассчитывающие на быструю работу с файлами после копирования.
Поймите меня правильно, я за reflink. Но не всё так однозначно. Да и CoW тут не при чём.
Ну у ZFS дедупликация просто онлайн, со всем вытекающим. А так да, вам никто не мешает ZFS пустить поверх VDO, если очень хочется. Только часто достаточно пользоваться сжатием, а дедупликация нужна не всегда.
Да, btrfs наиболее близок, жаль, что ещё не совсем стабилен.
ext4 — повреждение данных при этом пройдёт для вас незаметно, если правильно помню.
HAMMER NOVA NILFS ZFS Btrfs ReFQ SquashFS
Что из этого стабильно, доступно как RW ФС на Linux, кроме ZFS и btrfs? Не поймите меня не правильно, я буду только рад, если и другие ФС будут уметь такое.
Если люди полагаются только на целостность ФС и хранят важные данные в одном экземпляре — их не спасёт ни ZFS, ни магнитная лента, ни запекание лазером в алмазе. В данном случае, если нет другого дубликата данных — это ружьё, которое выстрелит, но когда-то потом. Серебряной пули действительно нет, но приятно что разработчики ZFS хотя бы двигаются в этом направлении.
Единственно добавлю, что по умолчанию из всех ФС только ZFS сейчас проверяет целостность данных. Никто не говорил, что после этого бекапы не нужны. Но только в этом случае вы хотя бы явно узнаете, что ваши данные в бекапе всё ещё не превратились в кашу.
Я сначала тоже так думал после анализа материалов, в которых описываются плюсы ZFS, но когда стал разбираться подробнее, оказалось что всё не так радужно, как кажется.
Да, серебряной пули нет :)
Самое больное — это если нужно расширить хранилище (с 2 до 3, с 3 до 4 дисков и т.п.), то это выходит дорого и неудобно, потому что в отличие от mdadm в RAIDZ нельзя добавить новое устройство — надо куда-то слить данные, которые лежат и заново создавать пул.
Расширение пула — самая что ни на есть штатная операция, наращивается новыми vdev устройствами (mirror, stripe, raidz). Для stripe всё даже круче — можно на лету добавить диск и сделать mirror. Да, сейчас в raidz нельзя просто так добавить диск, но работы в этом направлении ведутся тыц и тыц.
Плюс к этому всегда есть возможность на лету (!) увеличить любой vdev, заменив его диски на большие размером.
Ещё есть тревожные звоночки от людей, которые заменяли диски в пуле, у которых число секторов было меньше, чем в исходных.
Ну тут вообще нет претензий к ZFS. Как и в мифе про требование ECC памяти — оно может стрельнуть в ЛЮБОЙ ФС и менеджере дисков. А ZFS, как раз таки, по умолчанию создаёт 8МБ доп. пустой раздел, чтобы иметь манёвр на такой случай.
Судя по тестам (правда, чужие бенчмарки — это бабка надвое сказала), COW довольно сильно просаживает скорость чтения/записи.
На самом деле с производительностью всё нормально, если понимать особенности работы ZFS. Она в первую очередь обеспечивает безопасность данных, и вот тут да, мы будем получать накладные расходы в виде случайной записи-доступа и минимум 2 копий метаданных. При должной настройке во многих кейсах ZFS делает других. Во многих он также по умолчанию хуже :)
Также стоит понимать, что все плюшки ZFS используют ресурсы CPU по умолчанию больше, и при использовании всяких NVME полную скорость дисков выжать очень сложно (банально потому, что можно раньше упереться в CPU). Но это и не был первоначальный кейс ZFS, он затачивался под HDD, где задержки позволяют успеть сделать многое в CPU. Если кому интересно — тут как раз обсуждают и думают, как можно оптимизировать pipeline ZFS для NVME.
На самом деле (тут конечно наверняка палками побьют любители ZFS), почти всё можно реализовать средствами линуксовых dm/md — это lvm, mdadm, luks, vdo и т.п…
Можно собрать только отдалённо похожее, и по мере сборки производительность быстро упадёт ниже показателей ZFS, ну и аналога ARC кеша в принципе нет. А собрать аналог нельзя, потому что все эти layerы, кроме ext4/xfs/whateverFS не будут знать о данных. А вот здесь ZFS за счёт знания о данных и ARC/ZIL pipeline отлично оптимизирует производительность и даёт не плохие цифры.
Повторюсь — у разных инструментов разные цели. Брать ZFS и требовать от него только производительности, не изучив а на что он эту производительность тратит — ну, такое.
Часто люди делятся также и на ещё не получавших кашу из данных и не сталкивавшихся с fsck ext4/xfs, и на тех, кто уже пользуется ZFS :)))) Я готов отдать немного процентов производительности за целостность, атомарность, удобство использования, снапшоты, сжатие на лету, mirror/raidz и многое другое.
Linux-компьюнити совершенно право, что не интересуется проблемами разработчиков модулей с несовместимыми лицензиями.
Я уточню — оно (якобы) не интересуется ВООБЩЕ всеми сторонними модулями, не зависимо от их лицензий.
Сделайте совместимую лицензию да вливайтесь в апстрим, будет вам всё богатство ядра.
Скажите это Ораклу :) Всё, что не связано со старым кодом времён Sun — уже GPL-совместимо. Да и в апстрим вливаться — не самоцель. Просто зачем специально портить жизнь другой части opensource коммьюнити такими шагами?
Обобщение очень похоже на кнопку «Сделать хорошо», уж извините за сравнение :)
Эм, не приходит в голову кейс, когда нужно так делать. Уж лучше наоборот — primarycache=metadata и secondarycache=all, класть на l2arc только мету — уж лучше её держать в ОЗУ, а L2ARC если уж есть, то отдать на всё остальное.
Согласен, только я не понял что вы хотели сказать, изначально ваш вопрос был, как я понял, «когда использовать l2arc а когда special vdev».
L2ARC скоро будет персистентным, его кейс чисто про кеширование чтения, и он с этим справляется отлично. Special vdev конечно дал новые возможности, но кейс для L2ARC остался.
Ну всё же задачи у них разные, как и требования к резервированию, special class диски персистентны и их обязательно нужно резервировать.
А l2arc лучше обычно заменить добавлением озу.
Касаемо issue — проблема сейчас только в том, что данные со special class vdevs тоже будут кешироваться в l2arc. Если вам очень нужны оба — это не так критично, т.к. Метаданных по сравнению с данными всё равно сильно меньше.
CoW — это инструмент. Он не даёт магическим образом всё, что вы пожелаете.
Цель у каждого продукта своя. CoW — инструмент. В зависимости от целей он будет по разному использоваться. Почему вы пытаетесь притянуть ему желаемую в определённом продукте вами цель?
Давайте ещё раз — CoW магическим образом вам не даёт, к примеру, дедупликацию и снапшоты. Но, добавив ингредиенты (на примере ZFS — та же DDT), вы можете добиться нужной цели.
Не в ядре линука был придуман ни CoW, ни fork. https://en.wikipedia.org/wiki/Fork_(system_call) см. там же virtual memory в SunOS-4.0 от 1988 года.
Увы, но это не так, см. выше.
Вы вырвали из контекста как-то :) По умолчанию в CoW нет общих копий. Другой вопрос, что т.к. блок данных никогда не переписывается, позволяет его не удалять и использовать в других целях. Но это больше бонус, нежели цель.
И я вас расстрою — CoW всегда будет требовать больше пространства, чем классический подход. При заполнении более 90% любая CoW-like ФС начинает сильно деградировать по записи, т.к. свободное место дико фрагментировано и поиск свободного места нужного размера становится очень дорог. Да, это пытаются нивелировать всякими плюшками типа компрессии. Но это не основная цель CoW!
Это пример из конкретной реализации ZFS и причины, почему дедупликацию в ней НЕ рекомендуют включать. Конечно стоит добавить, что именно эту ситуацию тоже пытаются улучшить github.com/zfsonlinux/zfs/issues/405#issuecomment-57201194, но в этой презентации явно показана стоимость дедупликации. Кратко — она всё равно не бесплатна.
А, ну и если вам очень хочется reflink в ZFS — просто включите дедупликацию :) Даже cp менять не придётся. Только включать дедупликацию я не рекомендую, если ваш коэффициент дедупликации меньше 20, см. требования к ОЗУ выше. Лучше онлайн lz4 компрессию использовать.
Если найдёте тесты на доступ к reflinked файлам, близкие к реальным кейсам — было бы интересно на них посмотреть, спасибо!
IIRC не всё так радужно, было бы отлично найти реальные тесты работы ПО с включенным reflink, окромя ручного копирования. Часто файлы при работе лежат либо в tmpfs, либо на других ФС, и reflink тут не поможет. А просто так делать cp туда-сюда в рамках одной ФС — ну, такое.
Важный момент — тесты должны проверят скорость дальнейшей работы с reflinked файлами, иначе самое интересное вы как раз таки выкидываете за борт :) Вы в статье критикуете именно аргумент про производительность при изменении reflinked файла («Also for performance reasons you may want the writes to happen at copy time rather than some latency sensitive process working on a CoW file and being delayed by the writes possibly to a different part of a mechanical disk.»), а тесты именно на это не делаете.
Работа с дедуплицированными данными не всегда бесплатна.
Так и при чём тут CoW ФС, приследовавшие совершенно другие цели, как ранее уже сказал Enchant? Чисто технически можно и на ext4 сделать нашлёпку для reflink. Да, механизм будет похож на CoW, но блин, это не магические 3 буквы :)
Рассматривая ваше сравнение reflink со снапшотами — да, механизм похож, но это не значит, что в ФС со снапшотами вы автоматом получаете reflinks. На примере ZFS — всё есть дерево, при создании снапшота грубо говоря создаётся родительский блок, наследующий все предыдущие состояния датасета, и не позволяющий их удалять. Но снапшот здесь per-dataset. Reflink же требует не просто похожий механизм, но на уровне отдельного файла, но и ещё должен давать адекватную скорость при доступе к блокам reflinked файлов. Это же тоже не бесплатно, плюс выбивается из архитектуры данной ФС. Т.е. в ZFS снапшоты бесплатны именно на создание. Но удаление снапшотов — не бесплатно. То же самое, только хуже, будет и для reflink, где удаление будет происходить сильно чаще.
И, в случае ZFS, reflinks должны полагаться на DDT, а не на снапшоты github.com/zfsonlinux/zfs/issues/405#issuecomment-57201194
Так же и с аргументами про reflink — вы сами соглашаетесь с первым его аргументом. И, касаемо reflink — это нарушение стандартного поведения, не без последствий. А их без веской причины вообще менять не любят.
Вы приводите аргументы за 1 конкретный юзерский сценарий «быстро копировать файлы». В то время, как другие сценарии могут быть сильно весомее. И тут я согласен по поводу того, что при смене поведения сильно пострадают сценарии, рассчитывающие на быструю работу с файлами после копирования.
Поймите меня правильно, я за reflink. Но не всё так однозначно. Да и CoW тут не при чём.
Тем, что эти плюшки достаются не бесплатно, а какой-то ценой. По этой причине включать все возможности по умолчанию без обоснования — противопоказано.
ext4 — повреждение данных при этом пройдёт для вас незаметно, если правильно помню.
Что из этого стабильно, доступно как RW ФС на Linux, кроме ZFS и btrfs? Не поймите меня не правильно, я буду только рад, если и другие ФС будут уметь такое.
Единственно добавлю, что по умолчанию из всех ФС только ZFS сейчас проверяет целостность данных. Никто не говорил, что после этого бекапы не нужны. Но только в этом случае вы хотя бы явно узнаете, что ваши данные в бекапе всё ещё не превратились в кашу.
Да, серебряной пули нет :)
Расширение пула — самая что ни на есть штатная операция, наращивается новыми vdev устройствами (mirror, stripe, raidz). Для stripe всё даже круче — можно на лету добавить диск и сделать mirror. Да, сейчас в raidz нельзя просто так добавить диск, но работы в этом направлении ведутся тыц и тыц.
Плюс к этому всегда есть возможность на лету (!) увеличить любой vdev, заменив его диски на большие размером.
Ну тут вообще нет претензий к ZFS. Как и в мифе про требование ECC памяти — оно может стрельнуть в ЛЮБОЙ ФС и менеджере дисков. А ZFS, как раз таки, по умолчанию создаёт 8МБ доп. пустой раздел, чтобы иметь манёвр на такой случай.
На самом деле с производительностью всё нормально, если понимать особенности работы ZFS. Она в первую очередь обеспечивает безопасность данных, и вот тут да, мы будем получать накладные расходы в виде случайной записи-доступа и минимум 2 копий метаданных. При должной настройке во многих кейсах ZFS делает других. Во многих он также по умолчанию хуже :)
Также стоит понимать, что все плюшки ZFS используют ресурсы CPU по умолчанию больше, и при использовании всяких NVME полную скорость дисков выжать очень сложно (банально потому, что можно раньше упереться в CPU). Но это и не был первоначальный кейс ZFS, он затачивался под HDD, где задержки позволяют успеть сделать многое в CPU. Если кому интересно — тут как раз обсуждают и думают, как можно оптимизировать pipeline ZFS для NVME.
Можно собрать только отдалённо похожее, и по мере сборки производительность быстро упадёт ниже показателей ZFS, ну и аналога ARC кеша в принципе нет. А собрать аналог нельзя, потому что все эти layerы, кроме ext4/xfs/whateverFS не будут знать о данных. А вот здесь ZFS за счёт знания о данных и ARC/ZIL pipeline отлично оптимизирует производительность и даёт не плохие цифры.
Повторюсь — у разных инструментов разные цели. Брать ZFS и требовать от него только производительности, не изучив а на что он эту производительность тратит — ну, такое.
Часто люди делятся также и на ещё не получавших кашу из данных и не сталкивавшихся с fsck ext4/xfs, и на тех, кто уже пользуется ZFS :)))) Я готов отдать немного процентов производительности за целостность, атомарность, удобство использования, снапшоты, сжатие на лету, mirror/raidz и многое другое.
Да.
Я уточню — оно (якобы) не интересуется ВООБЩЕ всеми сторонними модулями, не зависимо от их лицензий.
Скажите это Ораклу :) Всё, что не связано со старым кодом времён Sun — уже GPL-совместимо. Да и в апстрим вливаться — не самоцель. Просто зачем специально портить жизнь другой части opensource коммьюнити такими шагами?
Более того, часто производители могу оставить на хосте как только USB, так и только mpcie/sata линии. Лотерея.
DIY вышел классный!
Может упустил, но чем не подошли варианты из Китая? К примеру, такой за 13$
https://s.click.aliexpress.com/e/qjn250A. Because we can?
special_small_blocks. Рекомендую обратиться к документации github.com/zfsonlinux/zfs/blob/master/man/man8/zpool.8#L541 github.com/zfsonlinux/zfs/pull/5182 github.com/zfsonlinux/zfs/blob/master/man/man8/zfs.8#L1525В рамках поддерживаемых запущенным кодом флагов — можете любые активировать, а некоторые — даже отключать.
zpool set feature@multi_vdev_crash_dump=enabled tank1