Comments 139
iSCSI может, но не своими средствами. Сначала нужно сделать zvol — вид датасета, предоставляющий интерфейс блочного устройства.
Делается легко, например:
zfs create -V 30G PoolName/volume_name
Где 30G — объем.
Затем такое блочное устройство нужно "расшарить" с помощью isci-tartet.
Снэпшоты и прочие радости ZFS доступны и для zvol.
интересно, как у этого метода с производительностью.
загрузка операционной системы с такого тома возможна?
Я только немного экспериментировал с iSCSI, поэтому о производительности такого use-case не могу глубоко рассуждать.
Но, в общем, производительность сильно зависит от конфигурации vdev.
Например, принято считать, что для ZRAID* — это производительность самого медленного в массиве HDD.
Страйп зеркал будет быстрее.
И еще скорость сильно проседает, если много операций синхронной записи. Тут либо ZIL, либо sync=disabled (если приемлемо) помогут.
Так же от параметра volsize и паттерна IO приложения зависит…
В общем, вооружившись fio и его конфигурацией, похожей на паттерн Вашего приложения, можно тюнить...
О, а подскажите, в сценарии, когда ZVOL, SSD и потому ext4 — при использовании ZVOL очень резко снижается количество свободного места (по сравнении с без ZVOL или просто ext4) и это очень чувствительно на ссд, которые и так маленькие. Нельзя ли на это как-то влиять?
Опишите полностью вашу установку, геометрию пула (mirror, raid-z).
Один ссд. Совсем один. На нем zvol. Размером на весь диск, для теста (потому что нам нужно одновременно сжатие и ext4), на zvol — ext4.
Подскажите, а зачем вам ext4 в такой конфигурации?
Мы привязаны к OpenVZ. OpenVZ привязана к ext4. При этом у нас очень хорошо сжимаемые данные и deduplication ratio за 100, поэтому хочется уровнем ниже ext4 иметь сжатие и дедупликацию. Правда на дедупликацию при блок сайз = 4к не всегда есть память (некоторые ссд за терабайт, в некоторых серверах 32гб памяти и нельзя поставить больше)
Сравниваю получившийся размер раздела после создания (т.е. диск пустой, раздел делается на весь диск).
Судя по логам, которые нашел сходу, у меня получалось так:
Тесты на ссд на 480 гигабайт.
Если просто ext4, то df -h показывает size = 441G
Если
zpool create -o ashift=9 vzpool /dev/sdb1
zfs create -o mountpoint=/vz2 vzpool/privateто получившийся size похоже то ли 440, то ли ~420.
Если
zpool create -o ashift=9 vzpool /dev/sdb1
zfs create -V 416G -o volblocksize=4k vzpool/vz2
mkfs.ext4 ...то size в df -h оказывался 383G
В цифрах могут быть ошибки, делал заметки по ходу тестирования, но порядок разницы примерно такой. Если нужно — могу найти сервер с свободным ссд и проверить снова.
Выставьте нужный ashift вашему ssd, очень маловероятно, что он 9 (512 байт на блок), к тому же некоторые производители указывают не фактический размер блока.
Т.к. Стандартный размер блока ext4 4kb, то создавать zvol лучше с таким же размером блока.
zfs create -b 4096 -V size volume
В основном это может быть влияние выставленного вами ashift.
Посчитал.
- если ext4 на 480гб SSD диске, то доступно 440 гигабайт.
- если просто ZFS то 430 гигабайт
- если ext4 на ZVOL — всего 398 гигабайт
Кстати, у ссд дисков (по крайней мере наших) размер сектора таки 512 байт. Все, конечно, наверное, знают, что любая запись там перезаписывает блок на 128к, но все же.
Статистика по размерам файлов (какие лучше выбрать параметры для блок сайз и прочего исходя из этого?)
- Средний размер маленького файла — чуть меньше 1 килобайта и таких файлов 65%
- Средний размер вообще — 9 килобайт
- Более 100 килобайт — средний размер ~500 килобайт и таких файлов 4%
- Более одного мегабайта — средний размер 11 мегабайт и таких файлов ~0.15%
Как все это считалось в красивом оформлении — https://gist.github.com/knutov/453fa860e4f574ac01413273cf79392f
И кстати, как я должен был угадать размер ZVOL, если я хотел сделать его на весь диск, и почему потом получилось больше?
Прокомментируйте пожалуйста это, возможно я делаю что-то неправильно?
Кстати, у ссд дисков (по крайней мере наших) размер сектора таки 512 байт
Не спорю, просто рекомендую проверить, в списках рассылки ZFS эта тема уже поднималась, есть некоторые модели дисков, у которых заявленное производителем не сходится с фактическим.
если ext4 на 480гб SSD диске, то доступно 440 гигабайт.
По приведённой вами ссылке я вижу другую цифру —
Если использовать 4 килобайта на иноду (что кажется логичнее), то свободного места на пустом диске будет меньше — 419GТо есть для ext4 по умолчанию доступно тоже меньше. Прошу точно описывать исходные данные, иначе диалог неконструктивен.
если ext4 на ZVOL — всего 398 гигабайт
Момент, который стоит учитывать в расчётах — метаданные. Естественно вы не заполните все 430гб сырого места пула. Чем больше будет volblocksize, тем меньше метаданных будет. Точный расчёт их размера произвести не так просто, т.к. они тоже сжимаются. Ссылка на тему. Т.к. вы используете -V (резервируете место), то ZFS съедает нужное количество места для гарантированной возможности записи зарезервированного места.
Плюс, как уже во многих комментариях и статье упоминалось, ZFS не предназначена для заполнения на 100%, что также ведёт к рекоммендациям не выделять всё место под ZVOL, при максимальном заполнении будут накладные расходы.
Функционал ZFS требует метаданных большего размера, чем другие ФС, контрольные суммы, снапшоты и другой функционал требует хранения, и чем меньше блок, тем больше метаданных будет.
Если я не указываю ashift (ashift=0) то zfs сам выбирает ashift=9.
Да, с размером блока недоработка была, поправил https://gist.github.com/knutov/453fa860e4f574ac01413273cf79392f
- если ext4 на 480гб SSD диске, то доступно 440 гигабайт (16к на иноду)
- если ext4 на 480гб SSD диске, то доступно 419 гигабайт (4к на иноду)
- если просто ZFS то 430 гигабайт
- если ext4 на ZVOL — 398 гигабайт (blocksize=4k)
- если ext4 на ZVOL — 417 гигабайт (blocksize=16k)
Но — размер блока ext4 и размер инода — разные вещи.
В тесте у ext4 везде размер блока оставлен по умолчанию ( -b 4096 ). В случае с ZVOL при блоксайзе 4к это 398 гигабайт вместо 440.
А вот если сделать блоксайз равный размеру инода (16к) — тогда да, получаем 417 гигабайт ext4 на zvol против 440 у ext4 без zfs, что лучше, но все равно — вы выше утверждали
место не должно съедаться больше, чем без zfs
а судя по тестам — это не так и без ZFS места намного больше.
Учитывая, что у меня SSD — вряд ли можно получить какую-то разницу в скорости работы при разных размерах чего угодно, по крайней мере на чтение. По этому, помня, что я хочу дефрагментацию и у 65% файлов размер менее 1 килобайта — разве не логичнее использовать более маленький volblocksize?
Но — размер блока ext4 и размер инода — разные вещи.
Спасибо, перепутал, но в данном случае не критично. Если вас устроит, что при запросе с диска ZFS будет выбирать блок до 16кб для любого маленького файла (а с учётом сжатия он в любом случае будет меньше), то увеличение blocksize=16k для вас целесообразно.
а судя по тестам — это не так и без ZFS места намного больше.
Извините, погорячился с утверждением, более корректно — ZFS требует дополнительного места под метаданные, в остальном всё так же.
Учитывая, что у меня SSD — вряд ли можно получить какую-то разницу в скорости работы при разных размерах чего угодно, по крайней мере на чтение.
Верно, рекомендую провести тестирование производительности и убедиться.
По этому, помня, что я хочу дефрагментацию
На дефрагментацию вообще не смотрите, до заполнения 80% диска она вас не потревожит, и пусть вас не смущает показатель fragmentation у zpool — он показывает приблизительную фрагментацию метаданных, не более.
и у 65% файлов размер менее 1 килобайта
Тут критично, каким блоком будет записывать эти файлы ext4, плюс сжатие поможет компенсировать эту проблему.
не логичнее использовать более маленький volblocksize
С одной стороны — да, но в ZFS чем больше размер блока — тем лучше для производительности и сжатия, и хуже для дедупликации. Что вам приоритетнее, то и стоит выбрать.
Тут критично, каким блоком будет записывать эти файлы ext4, плюс сжатие поможет компенсировать эту проблему.
Миллионы мелких файлов делятся на два типа — часть из них создается одномоментно — в момент разворачивания дистрибутива Битрикса. Если писать их на диск не сразу, то — наверное запись как-то агрегируется и они будут писаться блоками по 16к? Я ведь правильно думаю, что в одном блоке может быть больше одного файла?
Второй тип мелких файлов — кеш битрикса. Он не дедуплицируем, но сжимаем. Но многие файлы вообще по 200 байт. Вот тут мы сможем, видимо, получить большой выигрыш, если откажемся от ext4 — на чистом зфс вроде бы можно для отдельных каталогов дедупликацию отключить и поэкономить память.
то — наверное запись как-то агрегируется и они будут писаться блоками по 16к?
В рамках ZFS — да, но у вас дополнительно есть EXT4. Это, кстати, ухудшит дедупликацию, т.к. она проводится на уровне блоков.
получить большой выигрыш, если откажемся от ext4
Эх, вам бы от ext4 отказаться бы. На чистом ZFS случай битрикса можно очень классно настроить.
А вам точно нужна дедупликация ради ядра битрикса? Оно весит не так много и отлично сжимается. Или в планах ещё что-то?
Эх, вам бы от ext4 отказаться бы
Да с радостью бы, но у нас еще и OpenVZ, который жестко привязан...
точно нужна дедупликация ради ядра битрикса?
У нас на каждом диске их несколько сотен.
Мы сейчас используем бекапы с LZ4 и дедупликацией (borgbackup) — там просто фантастические цифры по сжатию, очень впечатляет.
(вдруг кто-то нагуглит этот тред и пригодится)
рекомендую проверить, в списках рассылки ZFS эта тема уже поднималась, есть некоторые модели дисков, у которых заявленное производителем не сходится с фактическим.
Очень нехватало ссылки, но внезапно нашел:
https://github.com/zfsonlinux/zfs/blob/master/cmd/zpool/zpool_vdev.c
И действительно, некоторые из наших ссд имеют реальный блок 4к, хотя репортуют о 512.
Снапшоты — отлично, да, быстро. Только надо помнить, что если данные меняются быстро, то скорость заполнения раздела при наличии снапшотов шустро увеличивается.
COW очень не бесплатный, увы.
В вашем примере могла сказаться фрагментация, ZFS по объективным причинам любит большое наличие свободного места.
ZFS по объективным причинам любит большое наличие свободного места.
Так добавьте это в статью. Узнать об этом, заполнив 100Тб — крайне неприятно, правда?
Ага, например, ужасную деградацию скорости записи после заполнения >80%. Особо доставляет, когда массив под 100ТБ.
Нужно всего лишь уменьшить значение metaslab_min_alloc_size (http://skeletor.org.ua/?p=3189) и запись будет быстрее. По дефолту оно слишком большое.
Так же можно отключить/включить prefetch, nocacheflush (смотря что там происходит). Если данные не сильно важны, можно выключить sync, увеличить время сброса кеша да диск (по дефолту раз в 5 секунд).
В целом, да, zfs немного медленнее, но это не значит, что её нельзя подтюнить для более быстрой работы.
Насчёт снепшотов (из практики cиспользования zfs). Если diff между снепшототами (или снепшотом и текущим состоянием) достаточно большой (гигабайты, десятки/сотни гигабайт), то разницу начинаешь замечать: нагрузка на диски при таком же количестве iosp'ов значительно выше (логично почему). Так что, снепшоты не полностью бесплатны и это нужно учитывать.
Нужно всего лишь уменьшить значение metaslab_min_alloc_size (http://skeletor.org.ua/?p=3189) и запись будет быстрее. По дефолту оно слишком большое.
Возможно, но возникают вопросы:
1) Инженеры Sun не понимали, что делали, что выбрали это значение на несколько порядков больше, чем «надо»?
2) Допустим, они ошиблись. Вы более-менее внятно понимаете — на что повлияет изменение этого параметра, где аукнется?
3) «будет быстрее» — насколько быстрее? Кто-то проводил тесты?
Это я всё к тому, что с ZFS обычно речь идет не о домашней файлопомойке, а о корпоративном хранилище, большом и ценном.
Я понимаю, что любая система требует настройки под конкретные задачи, но наобум крутить крутилки стораджа — это опасный путь. Он имеет право на жизнь, «безумству храбрых...» как говорится, но, согласитесь, не стоит рекомендовать его как серебряную пулю.
2) Данный параметр может «аукнуться», только если у вас опять станет много свободного места (50% и более) и тогда возможно снижение скорости записи по сравнению с дефектными значениями.
3) тесты я не проводил, так как они будут очень хосто-зависимы, но из практики скажу следующее: есть у меня несколько одинаковых по железу серверов и так же однотипными данными. Так вот, падение скорости на запись наблюдается только у одного из них, и то, при достижении планки в 95%.
А насчёт серебряной пули — она действительно, если таковой не является, то явно стремиться к ней и ближе, чем любая мне известная ФС (суммарное количество преимуществ действительно намного больше, чем у других). Другое дело, что работает она как пуля только в Solaris (ни во FreeBSD, ни в Linux она не является достаточно стабильной).
Я думал точно так же как и вы и ко всему скептически относился, пока не поработал с ней плотно несколько лет. И вот тогда понимаешь, что её можно приспособить, практически под любые условия:
— нужна стабильность? пожалуйста, есть
— нужна супер скорость? да, тоже есть (подтюнил и вперёд)
— нужно что-то среднее, да тоже не вопрос.
Как уже перечисляли в статье, основные её преимущества это:
— неубиваемость. Действительно, её практически невозможно разрушить в виду особенностей строения (при каждой транзакции на диск пишутся 2 метки в начале, 2 в конце, при этом пишутся по диагонали)
— простота снепшотов (никакой lvm или btrfs не будет удобным настолько, насколько это делается в zfs)
— autoexpand — это действительно вещь и в zfs это очень просто и безболезненно.
— множество фич, которые можно тюнить.
Так же забыл добавить, что можно налету изменять размер блоков, которыми ФС пишет на диск. К примеру, если у вас на zfs postgresql (а по дефолту она пишет 8кб блоками), то нужно выставить в этой zfs тоже 8кб, тогда скорость записи значительно будет эффективнее, чем дефолтными 128кб. А если этого не знать, то можно сказать, ооо, как медленно пишет (фу, какая плохая ФС), у меня на линуксе писало быстрее.
Точно так, если вы не являетесь DBA, то вы не сможете выжать из БД максимум, и будете говорить, почему медленно работает.
С btrfs — можете почитать официальную страницу btrfs gotchas, плюс в нём нет поддержки блочных устройств (в ZFS это ZVOL).
А что насчёт удобства, то для это наличии многих фич + простота использования.
btrfs subvolume [params]
в отличии от zfs:
zfs [params]
Мне удобнее писать меньше текста, выполняя команды. Если кому-то нравится набирать команды из 20-30 символов + иерархические ключи — можете портировать powershell.
то нужно выставить в этой zfs тоже 8кб, тогда скорость записи значительно будет эффективнее
А если дедупликация — то 320 байт на блок — это на вот этот record size, или там блок — что-то другое?
Вопрос был про является ли рекордсайз блоксайзом, но я увидел
# zfs get all | grep -i size
vzpool recordsize 128K default
vzpool/vz3 volsize 423G local
vzpool/vz3 volblocksize 16K -Т.е. правильно ли я понимаю, что это разные вещи, и если у меня маленький средний размер файла, то мне лучше уменьшать именно recordsize ?
А на что тогда влияет volblocksize? Т.е. я понимаю, что это минимальная перезаписываемая порция данных и помню, что COW, но теперь не понимаю как вообще надо выбирать volblocksize и в зависимости от чего.
И заодним, если SSD и я очень хочу иметь много заранее очищенных блоков (и часто запускаю fstrim), а из-за COW у меня будет занято сильно больше блоков диска, чем данных — можно ли как-то управлять количеством старых копий, чтобы их было поменьше? И, например, если мне не нужны снапшоты совсем — можно ли их отключить и что-нибудь сэкономить на этом?
является ли рекордсайз блоксайзом
recordsize используется для dataset, а для ZVOL его аналогом является volblocksize, соответственно на ZVOL recordsize не влияет.
как вообще надо выбирать volblocksize и в зависимости от чего
В зависимости от размера блока ФС, которая будет находиться в ZVOL, либо от минимального размера блока, каким вы в рамках этой ФС планируете оперировать.
много заранее очищенных блоков (и часто запускаю fstrim), а из-за COW у меня будет занято сильно больше блоков диска
Пока вы не используете снапшоты, то размер ZVOL увеличиваться не будет. Если вы создадите ZVOL в режиме sparse (т.н. thin-provisioning, который в случае с COW практически бесплатен), то trim будет освобождать место и ZVOL будет занимать на пуле только занятое данными место.
можно ли их отключить и что-нибудь сэкономить на этом?
Особо не сэкономите ничего, просто не пользуйтесь.
небольшая проблема в случае zfs on linux:
http://list.zfsonlinux.org/pipermail/zfs-announce/2015-September/000001.html
[zfs-announce] spl/zfs-0.6.5 released
* Removed metaslab_min_alloc_size, it was unused internally due to
prior changes.
А что там с лицензией? Получилось втащить zfs в ядро Linux? А то я давно не слежу за темой.
2.возможность резервирования как на уровне создания зеркал и аналогов RAID массивов
А аналог RAID-6 в ней есть (т.е. сохранность целостности при выходе из строя 2 физических дисков)?
в существующий массив RAID-Z нельзя добавить ещё один диск (пока)
уже запланировано? для домашнего использования очень не хватает
Но вопрос удобства всё же поднимается — в OpenZFS уже появилась возможность исключать диски.
ухты… новый алгоритм шифрования… ;)))
компрессия это а не шифрование
А рассматривается ли возможность ручного прогона дедубликации в отведённый даунтайм без необходимости включать его напостоянно? Есть один юзкейс (CI/DI сервера) когда происходит сильное дублирование данных и можно было бы по выходным прогонять дедубликатор (когда всё стоит и можно испоьзовать хоть всю память для этого). Но постоянно гонять никак т.к. память для работы нужна.
Миграция в течение нескольких часов одной виртуалки, потом еще нескольких, ребут жесткий хранилища со включенными виртуалками под ESXi — ожила хранилка, отключение дедупликации, миграция части виртуалок на другой СХД, потом обратно — старые остались дедуплицированными, а новые уже нет.
Общее решение — пересоздание массива с нуля только.
Ну вот в том-то и вопрос, что активация на постоянной основе спотыкается об требование памяти. Но одноразовые прогоны дедубликации по уже записанным данным может решить большинство ситуаций. Но этого как раз и не предусмотрено. Увы...
Сейчас требуется около 5гб ОЗУ на 1 тб данных, они требуются только в момент записи.
Хотелось бы сравнить скорость работы текущей реализации ZFS в Linux (Debian 9.0) и Solaris (OpenIndiana Hipster).
Команда выглядит примерно так:
zpool import -N -o readonly=on -f -R /pool -F -T <transaction_id>
A deferred free means that a block has been freed but cannot be used by the pool until TXG_DEFER_SIZE transactions groups later. For example, a block that is freed in txg 50 will not be available for reallocation until txg 52 (50 + TXG_DEFER_SIZE). This provides a safety net for uberblock rollback. A pool could be safely rolled back TXG_DEFERS_SIZE transactions groups and ensure that no block has been reallocated.
TXG_DEFER_SIZE = 2. Поэтому со 100% вероятностью можно восстановить только то, что было 2 транзакции назад. А если пул заполнен, то шансов ещё меньше.
Рекомендую все действия производить над копией массива.
Какие сейчас минимальные адекватные требования к оперативной памяти? Мне снапшоты zfs нравятся больше чем btrfs, но память на домашней машинке ограничена (8гб, 5 постоянно занято kvm-ками). Стоит пробовать?
У меня в таких условиях полёт нормальный. Только надо учитывать, что ARC кеш выглядит так, как будто какое-то приложение сожрало всю память. Хотя реально эта память свободно перераспределяется под нужды приложений по требованию. Короче в моём случае работает, хоть и выглядит странно.
Использую для тестирования приложений на больших БД, которые надо долго готовить для каждого прогона. А так пересоздал снапшот и готово. Очень доволен.
Ну я ничего не указывал специально. Кеш в некоторые моменты отъедает половину оперативки. Но если я в этот момент запускаю локально приложение с прода, которое заведомо съедает всю память, то ничего летального не происходит. Кеш отдаёт память этому приложению. Ну обмен с диском начинает ожидаемо тупить. Но он и так тупил в этом случае. Ещё до установки zfs. Сейчас мне даже кажется, что после остановки приложения система быстрее вылазит из тупежей. Но конкретных замеров не делал.
Или я где-то не прав?
# zpool get bootfs
NAME PROPERTY VALUE SOURCE
zboot bootfs zboot/ROOT local
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
zboot 621G 2,03T 136K legacy
zboot/ROOT 621G 2,03T 8,98G legacy
# mount | grep boot
zboot/ROOT on / type zfs (rw,relatime,xattr,posixacl)
Кто-то спрашивал про прозводительность (всё от IOPS дисков зависит, конфигурации RAID и кол-ва шпинделей). Вот на домашней системе
Сначала смешное:
# dd if=/dev/zero of=./zerodump.useless bs=128k count=102400
102400+0 records in
102400+0 records out
13421772800 bytes (13 GB, 12 GiB) copied, 1.9465 s, 6.9 GB/s
Т.е. это на самом деле данных было записано в X раз меньше — сжатие на лету.
# zfs get all zboot/ROOT | grep compress
zboot/ROOT compressratio 1.27x — zboot/ROOT compression lz4 inherited from zboot
zboot/ROOT refcompressratio 1.55x — -------
# time cp -r American\ Gods Dark\ Matter SG-1 tmp/
real 0m34.449s
user 0m0.016s
sys 0m1.524s
# du -hs tmp
5,3G tmp
5,3G/34.449s = .1538GB/s на копирование файлов с компрессией на одной и той-же FS.
T.e. это и чтение и запись одновременно. Примечание, — компрессия для файлов-фильмов, — бесполезная трата ресурсов ЦПУ, но на производительность I/O в данном случае мало влияет.
Скорость чтения и валидации данных на диске (zpool scrub zboot/ROOT):
ссылка на скрин nmon: http://imgur.com/oNXmm3H
Диски SATA III Seagate Barracuda 1TB в конфигурации RAID-10
config:
NAME STATE READ WRITE CKSUM
zboot ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
sda2 ONLINE 0 0 0
sdb2 ONLINE 0 0 0
mirror-1 ONLINE 0 0 0
sdc1 ONLINE 0 0 0
sdd1 ONLINE 0 0 0
mirror-2 ONLINE 0 0 0
sde1 ONLINE 0 0 0
sdf1 ONLINE 0 0 0
Как-то так.
Примечание, — компрессия для файлов-фильмов, — бесполезная трата ресурсов ЦПУ, но на производительность I/O в данном случае мало влияет.
В случае несжимаемых данный ZFS не проводит сжатие, можете об этом не волноваться.
на freebsd работает добавлением загрузчика:
dd if=/boot/zfsboot of=/dev/ada0 count=1 && dd if=/boot/zfsboot of=/dev/ada0 skip=1 seek=1024
Использую zfs как NAS хранилку, впринципе очень доволен. LZ4 сжатие вообще огонь, на датасторах виртуалки жмутся в среднем в 2.4 раза. Прогретый ARC от 94 — 98% чтения отдает с RAM, остальное забирает L2ARC и совсем немного приходится на hdd. Не используем дедубликацию, т.к. она имеет смысл быть при блоках 4к, а для этого требуется очень много памяти.
Пробывал варианты с
- centos7 + openzfs
- illumous — дистрибутив omnios
- solaris 11.2/11.3
В итоге остановился на конаничном — Solaris.
типовая конфигурация у нас это:
- Cisco UCS 240m4 ( cpu: 2 x E5-2699A v4, ram: 768gb, 2 x dual intel x520 10gbe, 2 x lsi sas 9200-8e )
- 216BE2C-R741JBOD / SC847E2C-R1K28JBOD
- SLOG: PX04SHB020 — очень рекомендую
- L2ARC: HUSMM1640ASS204
Тестировал fio как локально, так и экспортируюмую шару по NFSv4, так и iSCSI волум.
Linux
Плюсы:
- Нет проблем с железом / дровами
- Легко найти человека который знаком с linux
- Имеется поддержка nfsv 4.1
на этом пожалуй плюсы закончены
Минусы:
- производительность zfs меньше на процентов 15 по сравнению с тем же OmniOS, на локальных тестах + тестах по iscsi (использовал targetd lio) и на процентов 20% по сравнению с тестами по nfs.
- autoreplace для пула, т.к. каждый диск у нас видится по четырем путям, нам необходимо сконфигурировать multipathd таким образом, чтобы в названии он отоброжал физическое расположение диска — в идиале полка/слот. чтобы после замены диска он автоматически выполнял реплейс.
- т.к. я тестировал на centos7 при проблемах с производительностью мы имеет только счетчики из proc и стандартные утилиты типа iostat (в systemtap я не селен), что как мне кажется делает анализ производительности более сложным чем в случае с solaris base дистрибутивами.
- Кластер на базе Pacemaker + Corosync. Умные проверки придется пилить руками.
OmniOS
плюсы:
- Хорошая производительность как при локальных теста, так и при использовании nfs
- Имеется платный кластер — RSF-1 заточенный под кустарные схд
- Dtrace который облегчает поиск проблемных мест + множество готовых скриптов под него.
- Comstar уже интегрирован с zfs (ISCSI)
- Нет проблем с мультипазингом, MPxIO работает на ура.
- Отличное сообщество.
- FMD (fault managment daemon) — этот парень всегда пришлет письмо,
если у вас, что то сломалось (если конечно сервер и fmd еще живы). Расширяется за счет плагинов.
Минусы:
- Не на всем железе взлетит + проблема с драйверами, для современных 40гбе карточек.
- до недавнего времени была проблема с UEFI
- Админов знакомых с solaris в разы меньше.
Solaris 11.3
все плюсы из OmniOS, а так-же:
- Производительность раза в полтара выше чем у OmniOS и тем более Linux,
как я понимаю это связанно с фитчей efficiency block allocation
котарая появилас в 36-ой версии, пула если не изменяет память. - L2ARC остается горячим при переключении кластер (активной ноды) или перезагрузки
- в FMD
появились плагины io retired && zfs retired, которые отслеживают
события с I/O на диске и в случае например "дребезка" диска, помечают его
как failed и убирает из системы до выяснения обстоятельств - Sun Cluster — это парень имеет багатую историю и тесно интегрирован с
Solaris. Отлично работает, прост в использовании, вообщем нареканий нет.
Минусы:
- Сообщество на металинки достаточно "тухлое"
- Не на всем железе взлетит + проблема с драйверами, хотя дела обстоят не так
остро как с OmniOS, а если брать сервера от Oracle так проблем вообще нет. - Нет фитчи с асинхронным удалением датасетов, например датасеты размером в
50тб удаляются сутки или двое, но зато это операция не просаживает CPU как в случае с OpenZFS. - Админов знакомых с solaris в разы меньше.
- Comstar не кластирезуется из коробки, нужно допиливать.
Десклеймер: По поводу производительности, настройки openzfs на linux и
illumous я старался сделать как можно более одинаковыми. У Oracle ZFS естественно они отличались. Ну и естественно это мой личный опыт, ваше мнение/опыт могут отличаться.
По поводу использования zfs в качестве бэка для систем виртуализации, аля Linux KVM + ZFS — посмотрите проект SmartOS, он достаточно интересный и активно развивается компанией Joyent.
Эх, вот бы усилия Oracle да объединить с OpenZFS…
В начале 2016 года. Я вкратце описал почему выбор пал на Солярис, также я убежден в том, что на "родной" системе zfs работает стабильнее + fmd очень удобен в части проблем с дребезгом дисков, а также автоматического создания инцидентов о возникших проблемах. Обязательно затестирую релиз 0.7 на нотнике ))
btw, а что с "efficiency block allocation" в ZoL?
Я что-то не смог сходу разобраться в версиях и как версия 5000 относится к линейке версий в солярисе.
btw, а что с «efficiency block allocation» в ZoL?
Уточните, какая возможность конкретно интересует (желательно ссылкой), в этом направлении многое было сделано и в Oracle, и в OpenZFS.
Я что-то не смог сходу разобраться в версиях и как версия 5000 относится к линейке версий в солярисе.
OpenZFS версия 5000 базируется на версии 28 последнего релиза с открытым исходным кодом, далее новый функционал подключается через feature flags, об этом написано в статье.
Есть пересекающийся новый функционал, но его реализации несовместимы.
(я погуглил, но слово log не заметил, и потому родился вопрос)
Судя по гуглу — есть zpool version 36
36 Efficient log block allocationУ openzfs максимальная версия — 28, но, например, версия 37 — lz4 и lz4 у openzfs на сколько я вижу есть.
Поэтому непонятно что из того, что после 28ой версии, реально есть в 5000
Вы можете сопоставить пересечения, но технически даже реализации LZ4 у них не совместимы.
Нет фитчи с асинхронным удалением датасетов, например датасеты размером в
50тб удаляются сутки или двое, но зато это операция не просаживает CPU как в случае с OpenZFS.
Да, это действительно так. Если нужно удалить весь пул, то пользуюсь таким хаком: делаю zpool export, zpool create -f и всё. Новый пул создан меньше чем за минуту.
Рекомендую к просмотру, хоть материал и старенький, но концепция изложена полностью:
ZFS: The Last Word in File Systems — Part 1
ZFS: The Last Word in File Systems — Part 2
Я думаю сложно будет подобрать сопостовимые конфигурации, сравнивать по price/performance?
А если же мы говорим про варианты с избыточностью, то тут вообще всё просто — в crush map задаём «использовать osd одного хоста» и смотрим на результат.
Ключевое что в ceph было бы интересно в сравнении с zfs — абсолютная толерантость к ресайзу в любую сторону. Хоть вверх, хоть вниз. Плюс возможность работать с ним как blob-хранилищем напрямую, что может быть иногда интереснее, чем fs/блочное устройство.
Но фичи ладно. Интересно было бы raw-производительность сравнить.
Для больших инсталляций хочу сравнение производительности с ceph'ом
Ну если на текущем железе, то это не большая инсталяция ))
Без избыточности тестировать как мне кажется смысла тоже нет, т.к. тогда и
zfs можно собрать как raid0.
Если интересно, то в середине июля должнен получить очередное оборудование под NAS
( 2 сервера + 4-ре полки на 24-ре диска) можно попробывать на них.
По Объему схожая конфигурация это:
zfs pool (Solaris):
40 x mirror - hdd 10krpm
8 x slog - ssd
4 x l2arc - ssdceph (Linux 4.X)
replicated pool == 2 copies
node1:
20 x osd - hdd
4 x ssd == 20 journal partitions
node2:
20 x osd - hdd
4 x sdd == 20 journal partitionsБерем примерно 10% от общего полезного объема
fio --time_based --name=benchmark --size=3000g --runtime=1200 --filename=/dev/sdb --ioengine=libaio --randrepeat=0 --iodepth=128 --direct=1 --invalidate=1 --verify=0 --verify_fatal=0 --numjobs=1 --rw=write --blocksize=4k --group_reporting
fio --time_based --name=benchmark --size=3000g --runtime=1200 --filename=/dev/sdb --ioengine=libaio --randrepeat=0 --iodepth=128 --direct=1 --invalidate=1 --verify=0 --verify_fatal=0 --numjobs=1 --rw=randwrite --blocksize=4k --group_reporting
fio --time_based --name=benchmark --size=3000g --runtime=1200 --filename=/dev/sdb --ioengine=libaio --randrepeat=0 --iodepth=128 --direct=1 --invalidate=1 --verify=0 --verify_fatal=0 --numjobs=1 --rw=read --blocksize=4k --group_reporting
fio --time_based --name=benchmark --size=3000g --runtime=1200 --filename=/dev/sdb --ioengine=libaio --randrepeat=0 --iodepth=128 --direct=1 --invalidate=1 --verify=0 --verify_fatal=0 --numjobs=1 --rw=randread --blocksize=4k --group_reporting
fio --time_based --name=benchmark --size=3000g --runtime=1200 --filename=/dev/sdb --ioengine=libaio --randrepeat=0 --iodepth=128 --direct=1 --invalidate=1 --verify=0 --verify_fatal=0 --numjobs=1 --rw=readwrite --blocksize=4k --group_reportingтак?
Ключевое что в ceph было бы интересно в сравнении с zfs — абсолютная толерантость к ресайзу в любую сторону
Ну если говорить про пул, то да, уменьшить его нельзя, но если честно на своей практики и необходимости такой небыло, хотя опыт у каждого и кейсы разные. Если говорить про файловые системы, то изменение размера, это просто изменение квоты.
PS: за терминологию касательно цефа заранее извиняюсь + если тестировать будем, возможно будет полезно узнать какой то бест практис по тонкой настроки ceph.
Плюс на ceph'е лучше всё-таки blustore использовать, они его объявили production-ready этой весной.
Вставлю свои 5 копеек: Использую ZFS в связке с OwnCloud-сервером (как средство сихронизации пользовательских данных с Windows-машин на сервер через OwnCloud-клиент) + Samba + снапшоты.
Для себя, как администратора, сделал доступ к папке с данными через скрытый ресурс.
И через настройки Samba объяснил, как интерпретировать снапшоты ZFS:
[USERDATA$]
comment =
path = /owncloud/
public = yes
writable = no
guest ok = yes
guest only = yes
read only = yes
hosts allow = 192.168.0.2
create mask = 0777
directory mask = 0777
vfs objects = shadow_copy2
shadow: format = auto-%Y-%m-%d_%H.%M
shadow: sort = desc
shadow: snapdir = .zfs/snapshot
shadow: localtime = yes
Что мне это дало — на любом каталоге я могу вызвать в Explorer контекстное меню и выбрать пункт: Предыдущие версии. Вижу все предыдущие версии (zfs-auto-snap то работает), могу тут же их открыть и найти нужный файл нужной версии.
В добавок к этому в самом OwnCloud есть версионность и корзина.
В общем вариант, неубиваемый вирусами шифровальщиками — как бы на машине они не поработали (клиенткой) — на сервере все равно исходный вариант останется. Либо в OwnCloud, либо в ZFS.
tank/rc-544 50G 50G 0 100% /var/www/rc-544/data
При 100% забитом разделе при попытке удалить файл получаю ошибку:
rm: cannot remove ‘backupland.com.log’: Disk quota exceeded
Проблема обходится
cat /dev/null > backupland.com.log
после чего появляется чутка места и после можно уже удалить файл
Но мне кажется это какой-то мегакостыль, есть нормальное решение проблемы?
Плюс добавлю, что не рекомендуется заполнять пул больше, чем на 80%, дальше начнутся проблемы с фрагментированием. Последнее, что стоит делать с CoW — заполнять её на 100%, уже на 90% мониторинг обязан орать.
NAME USED AVAIL REFER MOUNTPOINT
tank 17.6T 7.81T 1.48T /home
создаю я подпул так:
/sbin/zfs create tank/rc-544 -o mountpoint=/var/www/rc-544/data -o quota=51200M
50 гиг это же не размер раздела, а квота по сути.
Или нужно делать quota+20%, а ограничивать через refquota?
К сожалению, ZFSonLinux развивается в основном за счёт энтузиастов с упором на продакшн, удобства для десктопов только начинают получать какое-то внимание. Всегда рады пулл реквестам!
Сделал такой тест:
/sbin/zfs create tank/rc-544 -o mountpoint=/var/www/rc-544/data -o quota=61440M
/sbin/zfs set refquota=51200M tank/rc-544
То есть размеру раздела добавляем 20% места, а квоту для пользователей делаем 50gb
Чтобы при бэкапе если раздел заполнится на 100% по факту будет ещё 20% места в запасе.
Ну и при попытке удалить опять получаем ошибку
rm: cannot remove ‘backupland.com.log’: Disk quota exceeded
/sbin/zfs create tank/rc-544 -o mountpoint=/var/www/rc-544/data -o quota=61440M
tank/rc-544 — quota — лимит на размер датасета, включая его дочерние датасеты
/sbin/zfs set refquota=51200M tank/rc-544
tank/rc-544 — refquota- лимит на размер датасета, исключая дочерние датасеты.
То есть никакого запаса нет, вы съели всё разрешённое место (упёршись в наименьшую квоту).
Рекомендую следить за местом и увеличивать его заранее, а не руками по факту. К сожалению, в ближайшее время это поведение точно не будет изменено.
Последнее, что стоит делать с CoW — заполнять её на 100%, уже на 90% мониторинг обязан орать.
Иногда события развиваются очень стремительно. Например чекаут корневой дериктории svn, с разворотом 1500 тегов, сделаных CI.
дальше начнутся проблемы с фрагментированием
Т.е. на ссд это не критично и повлиет мало?
Домашний NAS стал на шаг ближе, немогу не нарадоваться!
Насколько оправдано на сервере виртуализации, использовать 2gb ARC (с настройками по-умолчанию) + 80GB l2arc? Каким образом в подобной ситуации (с минимальным размером ARC) достигнуть максимума использования l2arc?
Спасибо!
Я бы советовал потратить деньги на ОЗУ, L2ARC на малых конфигурациях не особо вам поможет. Также стоит учесть, что пока L2ARC не сохраняет состояние между перезагрузками, и каждый раз требует «прогрева».
пока L2ARC не сохраняет состояние между перезагрузками, и каждый раз требует «прогрева».Вы уверены? Насколько я понял что это уже исправлено. Мои беглые тесты, показали, что l2arc — используется после перезагрузки. Вроде на баг треккере уже закрыты тикеты которые вопрошали об этом.
По калькулятору совсем не понял схему рассчётов, что-то зависит от размера блока записи, от типа записи. Но, я если честно (в силу отсутствия опыта и понимания всей картины в целом), не могу правильно аплицировать это на виртуализаию (в моём случае proxmox). Как будет вести запись вирт. машина — не знаю. Да и машины — разные.
Пока хочу попробовать под ARC отвести 2-3 гб., после чего смотреть процент попадания в l2arc. К сожалению, сервера не имеют физической возможности расширения ОЗУ.
Как Вы считаете, подобный подход имеет право на жизнь?
патч был представлен ещё в 2015 году
Стоит уточнить, что стабильный патч Nexenta ещё не выпущен.
Расчёт простой — на каждый блок в L2ARC нужно ~200байт ОЗУ, для виртуализации скорее всего вы будете использовать zvol с volblocksize=8kb, соответственно на 100гб L2ARC потребуется около 2.5гб ОЗУ, на практике будет меньше.
Если у вас уже есть ssd, то проведите бенчмарк, иначе для начала просто настройте ограничение на ARC и попробуйте. Главное правильно настроить proxmox, volblocksize должен соответствовать блоку гостевой системы.
Производительность будет зависеть от особенностей ваших данных, если горячие данные поместятся в ваши 3гб ОЗУ, то это лучше, чем L2ARC.
на 100гб L2ARC потребуется около 2.5гб ОЗУ
Эта область ОЗУ сама будет забираться из ARC? Или максимально отводимая область под l2arc, будет регулироваться параметром: vfs.zfs.arc_meta_limit?
https://github.com/zfsonlinux/zfs/issues/1420#issuecomment-16831663
Да.
Вот интересная информация по этой теме.
Добавлю, что в релизе 0.7 требования к ОЗУ сильно оптимизированы, и в вашем случае может помочь (но он ещё в стадии тестирования, без бекапов ставить не рекомендую).
Если я верно понял, то у товарища из треда не удалялся mirror устройство, после чего, он получил объяснение, что это может происходить из-за не достатка памяти в ARC и слишком большого l2arc.
В следствии чего, он получил рекомендацию или увеличить ОЗУ для arc, или уменьшить разделы l2arc.
Если я Вас понял верно, то для 4GB RAM отведенного под ARC, мне следует ограничить l2arc размером в 60GB, тогда, в среднем, у меня будет уходить для l2arc не более 2gb RAM + 1 GB будет оставаться для собственно ARC и 1 GB под vfs.zfs.arc_meta_limit. При этом, vfs.zfs.arc_meta_limit мне не следует трогать.
Все ли верно понимаю?
Релиз 0.7, пока мне рановато применять, так-как планирую zfs в продуктивную установку.
не удалялся mirror устройство
Я дал ссылку на комментарий основного контрибьютора Brian Behlendorf, в котором он разъяснял требования к ОЗУ, касающиеся первого поста в тикете (проблема с производительностью при увеличении L2ARC). Проблема с mirror не касается обсуждаемого нами.
Все ли верно понимаю?
Всё верно, l2arc можете увеличивать по надобности без даунтайма, если ssd позволяет. arc_meta_limit стоит трогать только если выделенный объём l2arc не заполнится.
Если от arc_meta_limit, выходит:
ARC = 4GB
arc_meta_limit (25% от 4GB) = 1GB
volblocksize = 8kb
По формуле выходит 40GB — максимальный размер l2arc, если отталкиваюсь от arc_meta_limit.
Как понять сколько у меня реально испольузется l2arc? Всё же, arc_meta_used, насколько я понял, косвенный параметр.
За сим откланяюсь, больше не буду приставать с вопросами. Ответы на эти вопросы ищу с 2013 года, но так внятности не получил. По этому очень рад возможности спросить у компетентного разработчика!
Вообще, это тянет на отдельную статью на Хабре.
Ведь есть ещё вопрос по размеру zlog, там я понял чуть проще, размер должен быть таков, чтобы максимум за 5-10 секунд туда успела влезть вся запись с режимом sync.
Спасибо!
Статистика по заполнению l2arc есть, к примеру в Linux можно посмотреть
cat /proc/spl/kstat/zfs/arcstats
Рекомендую без донастроек проверить заполняемость, и только после этого по надобности тюнить arc_meta_limit, т.к. 200 байт ОЗУ на 1 блок l2arc — максимальный расчёт, а не фактический.
На ZFS-зеркало из пары шпиндельных HDD 500GB максимально дефолтно накатил под i5/16GB для экспериментов.
А в Hetzner сложнее — нет у них автоматизированной процедуры и возможности поставить Proxmox корнем на ZFS без заказа консолей и прочих извратов. В итоге хост поставил на BTRFS-зеркало небольшое, а 200GB под виртуалки разбил вручную, сверяясь с дефолтными параметрами экспериментальной машинки. Вроде конфиги не отличаются. Но Хетцнер — это пара Xeon-ов и Интеловские SSD.
И вот вопрос. Почему оно выдаёт такие низкие значения IO?
i5/16GB/2xHDD:
CPU BOGOMIPS: 23947.04 REGEX/SECOND: 1604707 HD SIZE: 300.58 GB (rpool/ROOT/pve-1) FSYNCS/SECOND: 83.9
2xXeon/32GB/2xSSD
CPU BOGOMIPS: 54394.40 REGEX/SECOND: 2948181 HD SIZE: 68.60 GB (rpool/data) FSYNCS/SECOND: 36.28
Это включенная компрессия LZ4 так влияет или CoW или что-то ещё? Без ZFS вроде (на старом Promox) сотни FSYNCS выдавало… но в целом серверу скорости хватает, а плюшки (снапшоты для бэкапов, сжатие) наверное перевешивают.
Может, не стоит заморачиваться? Или всё же что-то неверно настроено, и даже не руками, а дефолты Proxmox?
Если вам не критично потерять информацию за последние 5-10 секунд, то вы можете выставить настройку пула sync=disabled, в таком случае ZFS не будет сбрасывать информацию на диск по команде программ, а делать это с определённой периодичностью. Но это повышает производительность за счёт риска потерять записанную информацию за последние 30 секунд (при этом сама ФС на диске битой не будет, можете не переживать).
Ну при сбое питания вы в любом случае теряете последние данные, файлы, как и БД, и так и так не допишутся. Только ZFS пишет транзакционно, то есть риск повреждения уже минимален, если блок не дозаписался (причина поломки БД), то при загрузке будет использован предыдущий корректный.
Да, риск проблем с ПО при сбое питания есть всегда, в этом не спорю, но ФС в этом случае не повредится.
Разбираемся в ZFS
И еще вопрос про iSCSI (btw, спасибо вам огромное, что отвечаете здесь на вопросы)
Сценарий — очень много мелких файлов, которые постоянно используются + много больших архивов, которые один раз пишутся (скорость, с которой они пишутся, не имеет значения) и часто больше даже не читаются. Хочется скорость (SSD) и сэкономить денег. Таких серверов много.
Будет ли хорошим такое решение:
Сделать один отдельный NAS с обычными 3.5 дисками (+ arc побольше и l2arc какой-то), подцеплять его по iSCSI на рабочий сервер по гигабитной(!) сети (помним — хочется сэкономить, а скорость работы с большими файлами не важна), а на рабочих серверах поставить SSD под l2arc, размером как все мелкие файлы для этого сервера + какой-то запас?
Правильно ли я думаю, что в этом случае все данные будут в локальном l2arc и скорость работы с ними будет такая же, как если бы они были на локальном диске?
Будет ли оставаться l2arc кеш между рестартами сервера? ZOL последней версии. Если не будет, то будет ли в следующей 0.7 ?
(+ arc побольше и l2arc какой-то),
l2arc с записью не поможет, он только на чтение, для ускорения записи можете посмотреть ZIL, или просто отключить sync=disabled, но только в случае хорошего резервирования по питанию (риск потери данных за последние 30 секунд). Т.к. сеть у вас гигабитная, то проще всего просто поставить побольше оперативки на NAS и всё, скорее всего вы упрётесь в гигабит даже на 1 диске (если включите sync=disabled).
а на рабочих серверах поставить SSD под l2arc
Я пользуюсь в основном локально ZFS, но, насколько я знаю, такая схема невозможна (ZFS у вас на стороне NAS).
Если вы в основном пишете, то кеш со стороны клиента особо смысла не имеет.
Будет ли оставаться l2arc кеш между рестартами сервера? ZOL последней версии. Если не будет, то будет ли в следующей 0.7 ?
Пока он не постоянный, патч уже есть, но когда он будет включён в stable ветку — точно сказать невозможно. Думаю, что через год.
спасибо вам огромное, что отвечаете здесь на вопросы
Всегда рад помочь!
очень много мелких файлов, которые постоянно используются
Ой, извините, пропустил. В таком случае будет работать стандартный кеш Linux на стороне клиента, тут стоит изучить скорее ISCSI.
На NAS можно использовать L2ARC и ZIL, но лучше начать с увеличения RAM до максимально возможного и использования ARC. Советы по поводу sync выше менее актуальны.
насколько я знаю, такая схема невозможна (ZFS у вас на стороне NAS).
Идея была — на NAS сделать ZVOL, его отдать по iSCSI, на клиенте это будет блочное устройство, на которое можно сделать ZFS со стороны клиента, и тогда, вроде бы, к ZFS должно быть можно сделать l2arc и ZIL. Или я неправильно думаю?
Прежде всего большое спасибо за статью. Очень интересно и вдохновляюще. Решил после неё поэкспериментировать над нашим CI. Суть в том, что там крутится много разных задач, которые пересобирают в разных вариантах одни и те же исходники. В результате получается огромное дублирование данных. В ближаёшее время надо будет увеличить количество задач и количество обрабатываемых исходников. Как следствие нужно или значительно расширять дисковое пространство или как-то дедублицировать данные на диске.
Дай, думаю, попробую дедубликацию ZFS:
Взял виртуалку на нашем proxmox. Отрезал для тестов 100G том, создал пул:
zpool create -f -O compression=lz4 -O dedup=on -O recordsize=4096 -O atime=off -O sync=disabled -O relatime=on -m /storage jenkins /dev/vdeОперативки выдал 24G.
Сначала вроде всё полетело нормально, но потом начал замечать, что периодически ZFS уходит в жирный IO wait, останавливая все процессы.
По расчётам процессы не должны выедать больше 6-8G памяти.
То-ли под ARC памяти не хватает, то-ли чего… Пока опыт небольшой — не могу понять как это корректно диагностировать и куда смотреть.
Буду рад любой помощи.
Если ОЗУ хватает, то стоит смотреть, в какой момент именно возникает проблема, что съелось и др., в части arc может помочь
cat /proc/spl/kstat/zfs/arcstats
Кстати, вам точно нужен relatime?
Чуть не забыл, срочно включите xattr=sa, на большом количестве мелких файлов иначе будет сильное просаживание производительности, об этом упоминал в статье.
Огромное спасибо за ответ. Статью читал сразу после публикации, так что некоторые детали успел запамятовать, а сейчас читал по диагонали и просмотрел про xattr. Каюсь. Остальное тоже попробую. Ну и по поводу relatime — нет, не уверен :-). Тоже можно поиграться.
Спасибо за советы. Немного подрихтовал стало значительно лучше. По сути пересоздал том:
zpool create -f -O compression=lz4 -O dedup=on -O recordsize=128K -O atime=off -O sync=disabled -O relatime=off -O xattr=sa -m /storage jenkins /dev/vdeИ перезалил туда данные.
По дороге наткнулся ещё на одну граблю: на CentOS сильно мешает работе SELinux. Пытаюсь выполнить следующий скрипт:
hg clone -U http://host/hg/core
cd core
hg hg update --clean --rev 2c16204ae20ee88aa9d4641c23907b400b82fca9Т.е., по сути склонировать меркуриаловский репозиторий без развёртывания локальной копии файлов, перейти в каталог и встать на конкретную ревизию (собственно развернуть файлы этой ревизии). Так вот: первые две команды всегда проходят нормально, а вот последняя с некоторым небольшим шансом падает. То говорит, что подкаталой какой-либо не найден, то прав нехватает, то ещё что… При том, что половину репозитория успешно разворачивает, а потом падает.
Отключение SELinux решило проблему.
ZFS on Linux: вести с полей 2017