Такая реализация возможна, но, по моему, в ней получается много уровней абстракции.
ZVOL -> ISCSI -> EXT4 по моему будет более производительной, но при канале в 1гбит\сек ваш вариант может дать выигрыш.
Хотя меня и не покидает чувство, что это не правильно.
очень много мелких файлов, которые постоянно используются
Ой, извините, пропустил. В таком случае будет работать стандартный кеш Linux на стороне клиента, тут стоит изучить скорее ISCSI.
На NAS можно использовать L2ARC и ZIL, но лучше начать с увеличения RAM до максимально возможного и использования ARC. Советы по поводу sync выше менее актуальны.
l2arc с записью не поможет, он только на чтение, для ускорения записи можете посмотреть ZIL, или просто отключить sync=disabled, но только в случае хорошего резервирования по питанию (риск потери данных за последние 30 секунд). Т.к. сеть у вас гигабитная, то проще всего просто поставить побольше оперативки на NAS и всё, скорее всего вы упрётесь в гигабит даже на 1 диске (если включите sync=disabled).
а на рабочих серверах поставить SSD под l2arc
Я пользуюсь в основном локально ZFS, но, насколько я знаю, такая схема невозможна (ZFS у вас на стороне NAS).
Если вы в основном пишете, то кеш со стороны клиента особо смысла не имеет.
Будет ли оставаться l2arc кеш между рестартами сервера? ZOL последней версии. Если не будет, то будет ли в следующей 0.7 ?
Пока он не постоянный, патч уже есть, но когда он будет включён в stable ветку — точно сказать невозможно. Думаю, что через год.
спасибо вам огромное, что отвечаете здесь на вопросы
recordsize используется для dataset, а для ZVOL его аналогом является volblocksize, соответственно на ZVOL recordsize не влияет.
как вообще надо выбирать volblocksize и в зависимости от чего
В зависимости от размера блока ФС, которая будет находиться в ZVOL, либо от минимального размера блока, каким вы в рамках этой ФС планируете оперировать.
много заранее очищенных блоков (и часто запускаю fstrim), а из-за COW у меня будет занято сильно больше блоков диска
Пока вы не используете снапшоты, то размер ZVOL увеличиваться не будет. Если вы создадите ZVOL в режиме sparse (т.н. thin-provisioning, который в случае с COW практически бесплатен), то trim будет освобождать место и ZVOL будет занимать на пуле только занятое данными место.
можно ли их отключить и что-нибудь сэкономить на этом?
Особо не сэкономите ничего, просто не пользуйтесь.
Но — размер блока ext4 и размер инода — разные вещи.
Спасибо, перепутал, но в данном случае не критично. Если вас устроит, что при запросе с диска ZFS будет выбирать блок до 16кб для любого маленького файла (а с учётом сжатия он в любом случае будет меньше), то увеличение blocksize=16k для вас целесообразно.
а судя по тестам — это не так и без ZFS места намного больше.
Извините, погорячился с утверждением, более корректно — ZFS требует дополнительного места под метаданные, в остальном всё так же.
Учитывая, что у меня SSD — вряд ли можно получить какую-то разницу в скорости работы при разных размерах чего угодно, по крайней мере на чтение.
Верно, рекомендую провести тестирование производительности и убедиться.
По этому, помня, что я хочу дефрагментацию
На дефрагментацию вообще не смотрите, до заполнения 80% диска она вас не потревожит, и пусть вас не смущает показатель fragmentation у zpool — он показывает приблизительную фрагментацию метаданных, не более.
и у 65% файлов размер менее 1 килобайта
Тут критично, каким блоком будет записывать эти файлы ext4, плюс сжатие поможет компенсировать эту проблему.
не логичнее использовать более маленький volblocksize
С одной стороны — да, но в ZFS чем больше размер блока — тем лучше для производительности и сжатия, и хуже для дедупликации. Что вам приоритетнее, то и стоит выбрать.
Уточните, какая возможность конкретно интересует (желательно ссылкой), в этом направлении многое было сделано и в Oracle, и в OpenZFS.
Я что-то не смог сходу разобраться в версиях и как версия 5000 относится к линейке версий в солярисе.
OpenZFS версия 5000 базируется на версии 28 последнего релиза с открытым исходным кодом, далее новый функционал подключается через feature flags, об этом написано в статье.
Есть пересекающийся новый функционал, но его реализации несовместимы.
Кстати, у ссд дисков (по крайней мере наших) размер сектора таки 512 байт
Не спорю, просто рекомендую проверить, в списках рассылки ZFS эта тема уже поднималась, есть некоторые модели дисков, у которых заявленное производителем не сходится с фактическим.
если ext4 на 480гб SSD диске, то доступно 440 гигабайт.
По приведённой вами ссылке я вижу другую цифру —
Если использовать 4 килобайта на иноду (что кажется логичнее), то свободного места на пустом диске будет меньше — 419G
То есть для ext4 по умолчанию доступно тоже меньше. Прошу точно описывать исходные данные, иначе диалог неконструктивен.
если ext4 на ZVOL — всего 398 гигабайт
Момент, который стоит учитывать в расчётах — метаданные. Естественно вы не заполните все 430гб сырого места пула. Чем больше будет volblocksize, тем меньше метаданных будет. Точный расчёт их размера произвести не так просто, т.к. они тоже сжимаются. Ссылка на тему. Т.к. вы используете -V (резервируете место), то ZFS съедает нужное количество места для гарантированной возможности записи зарезервированного места.
Плюс, как уже во многих комментариях и статье упоминалось, ZFS не предназначена для заполнения на 100%, что также ведёт к рекоммендациям не выделять всё место под ZVOL, при максимальном заполнении будут накладные расходы.
Функционал ZFS требует метаданных большего размера, чем другие ФС, контрольные суммы, снапшоты и другой функционал требует хранения, и чем меньше блок, тем больше метаданных будет.
Скорее всего у вас сочетание ashift=9 и несоответствующего ext4 volblocksize.
Выставьте нужный ashift вашему ssd, очень маловероятно, что он 9 (512 байт на блок), к тому же некоторые производители указывают не фактический размер блока.
Т.к. Стандартный размер блока ext4 4kb, то создавать zvol лучше с таким же размером блока.
zfs create -b 4096 -V size volume
В основном это может быть влияние выставленного вами ashift.
Если не создаются снапшоты, то место не должно съедаться больше, чем без zfs. Также можете попробовать на ext4 провести trim, после этого zfs отобразит только занятое место, скорее всего это вас смущает (zfs под занятым местом в zvol понимает любой когда-либо аллоцированный блок, не освобождённый).
Подскажите, а зачем вам ext4 в такой конфигурации?
Ну при сбое питания вы в любом случае теряете последние данные, файлы, как и БД, и так и так не допишутся. Только ZFS пишет транзакционно, то есть риск повреждения уже минимален, если блок не дозаписался (причина поломки БД), то при загрузке будет использован предыдущий корректный.
Да, риск проблем с ПО при сбое питания есть всегда, в этом не спорю, но ФС в этом случае не повредится.
Пролистал, в этой статье есть злые советы, которые хотят съесть ваши данные:
— RAID-Z1 не рекомендуется к использованию, лучше использовать RAID-Z2, который выдержит отказ 2 дисков;
— параметр copies=3 никак не спасает от выхода из строя 2х дисков из 3х в RAID-Z1.
Вот тред на форуме Proxmox, в котором есть отзывы о том, что эти измерения не сходятся с фактической производительностью.
Если вам не критично потерять информацию за последние 5-10 секунд, то вы можете выставить настройку пула sync=disabled, в таком случае ZFS не будет сбрасывать информацию на диск по команде программ, а делать это с определённой периодичностью. Но это повышает производительность за счёт риска потерять записанную информацию за последние 30 секунд (при этом сама ФС на диске битой не будет, можете не переживать).
Да, arc_meta_limit ограничивает максимальное количество метаданных в кеше, а записи о l2arc являются метаданными.
Статистика по заполнению l2arc есть, к примеру в Linux можно посмотреть
cat /proc/spl/kstat/zfs/arcstats
Рекомендую без донастроек проверить заполняемость, и только после этого по надобности тюнить arc_meta_limit, т.к. 200 байт ОЗУ на 1 блок l2arc — максимальный расчёт, а не фактический.
С lvm всё просто — они там не «бесплатные», накладывают большой отпечаток по производительности, сама ФС о снапшотах ничего не знает.
С btrfs — можете почитать официальную страницу btrfs gotchas, плюс в нём нет поддержки блочных устройств (в ZFS это ZVOL).
ZVOL -> ISCSI -> EXT4 по моему будет более производительной, но при канале в 1гбит\сек ваш вариант может дать выигрыш.
Хотя меня и не покидает чувство, что это не правильно.
Ой, извините, пропустил. В таком случае будет работать стандартный кеш Linux на стороне клиента, тут стоит изучить скорее ISCSI.
На NAS можно использовать L2ARC и ZIL, но лучше начать с увеличения RAM до максимально возможного и использования ARC. Советы по поводу sync выше менее актуальны.
l2arc с записью не поможет, он только на чтение, для ускорения записи можете посмотреть ZIL, или просто отключить sync=disabled, но только в случае хорошего резервирования по питанию (риск потери данных за последние 30 секунд). Т.к. сеть у вас гигабитная, то проще всего просто поставить побольше оперативки на NAS и всё, скорее всего вы упрётесь в гигабит даже на 1 диске (если включите sync=disabled).
Я пользуюсь в основном локально ZFS, но, насколько я знаю, такая схема невозможна (ZFS у вас на стороне NAS).
Если вы в основном пишете, то кеш со стороны клиента особо смысла не имеет.
Пока он не постоянный, патч уже есть, но когда он будет включён в stable ветку — точно сказать невозможно. Думаю, что через год.
Всегда рад помочь!
Вы можете сопоставить пересечения, но технически даже реализации LZ4 у них не совместимы.
recordsize используется для dataset, а для ZVOL его аналогом является volblocksize, соответственно на ZVOL recordsize не влияет.
В зависимости от размера блока ФС, которая будет находиться в ZVOL, либо от минимального размера блока, каким вы в рамках этой ФС планируете оперировать.
Пока вы не используете снапшоты, то размер ZVOL увеличиваться не будет. Если вы создадите ZVOL в режиме sparse (т.н. thin-provisioning, который в случае с COW практически бесплатен), то trim будет освобождать место и ZVOL будет занимать на пуле только занятое данными место.
Особо не сэкономите ничего, просто не пользуйтесь.
Спасибо, перепутал, но в данном случае не критично. Если вас устроит, что при запросе с диска ZFS будет выбирать блок до 16кб для любого маленького файла (а с учётом сжатия он в любом случае будет меньше), то увеличение blocksize=16k для вас целесообразно.
Извините, погорячился с утверждением, более корректно — ZFS требует дополнительного места под метаданные, в остальном всё так же.
Верно, рекомендую провести тестирование производительности и убедиться.
На дефрагментацию вообще не смотрите, до заполнения 80% диска она вас не потревожит, и пусть вас не смущает показатель fragmentation у zpool — он показывает приблизительную фрагментацию метаданных, не более.
Тут критично, каким блоком будет записывать эти файлы ext4, плюс сжатие поможет компенсировать эту проблему.
С одной стороны — да, но в ZFS чем больше размер блока — тем лучше для производительности и сжатия, и хуже для дедупликации. Что вам приоритетнее, то и стоит выбрать.
Уточните, какая возможность конкретно интересует (желательно ссылкой), в этом направлении многое было сделано и в Oracle, и в OpenZFS.
OpenZFS версия 5000 базируется на версии 28 последнего релиза с открытым исходным кодом, далее новый функционал подключается через feature flags, об этом написано в статье.
Есть пересекающийся новый функционал, но его реализации несовместимы.
Не спорю, просто рекомендую проверить, в списках рассылки ZFS эта тема уже поднималась, есть некоторые модели дисков, у которых заявленное производителем не сходится с фактическим.
По приведённой вами ссылке я вижу другую цифру — То есть для ext4 по умолчанию доступно тоже меньше. Прошу точно описывать исходные данные, иначе диалог неконструктивен.
Момент, который стоит учитывать в расчётах — метаданные. Естественно вы не заполните все 430гб сырого места пула. Чем больше будет volblocksize, тем меньше метаданных будет. Точный расчёт их размера произвести не так просто, т.к. они тоже сжимаются. Ссылка на тему. Т.к. вы используете -V (резервируете место), то ZFS съедает нужное количество места для гарантированной возможности записи зарезервированного места.
Плюс, как уже во многих комментариях и статье упоминалось, ZFS не предназначена для заполнения на 100%, что также ведёт к рекоммендациям не выделять всё место под ZVOL, при максимальном заполнении будут накладные расходы.
Функционал ZFS требует метаданных большего размера, чем другие ФС, контрольные суммы, снапшоты и другой функционал требует хранения, и чем меньше блок, тем больше метаданных будет.
Выставьте нужный ashift вашему ssd, очень маловероятно, что он 9 (512 байт на блок), к тому же некоторые производители указывают не фактический размер блока.
Т.к. Стандартный размер блока ext4 4kb, то создавать zvol лучше с таким же размером блока.
В основном это может быть влияние выставленного вами ashift.
Подскажите, а зачем вам ext4 в такой конфигурации?
Опишите полностью вашу установку, геометрию пула (mirror, raid-z).
Ну и ставить лучше на отдельный раздел, согласен с предыдущим комментатором, производительность всё же не высокая.
В RAID-Z IOPS самого медленного диска, последовательная запись в норме.
Ну при сбое питания вы в любом случае теряете последние данные, файлы, как и БД, и так и так не допишутся. Только ZFS пишет транзакционно, то есть риск повреждения уже минимален, если блок не дозаписался (причина поломки БД), то при загрузке будет использован предыдущий корректный.
Да, риск проблем с ПО при сбое питания есть всегда, в этом не спорю, но ФС в этом случае не повредится.
— RAID-Z1 не рекомендуется к использованию, лучше использовать RAID-Z2, который выдержит отказ 2 дисков;
— параметр copies=3 никак не спасает от выхода из строя 2х дисков из 3х в RAID-Z1.
Если вам не критично потерять информацию за последние 5-10 секунд, то вы можете выставить настройку пула sync=disabled, в таком случае ZFS не будет сбрасывать информацию на диск по команде программ, а делать это с определённой периодичностью. Но это повышает производительность за счёт риска потерять записанную информацию за последние 30 секунд (при этом сама ФС на диске битой не будет, можете не переживать).
Статистика по заполнению l2arc есть, к примеру в Linux можно посмотреть
Рекомендую без донастроек проверить заполняемость, и только после этого по надобности тюнить arc_meta_limit, т.к. 200 байт ОЗУ на 1 блок l2arc — максимальный расчёт, а не фактический.
С btrfs — можете почитать официальную страницу btrfs gotchas, плюс в нём нет поддержки блочных устройств (в ZFS это ZVOL).