George
т.е. без сжатия с recordsize=16M 17МБ файл займёт 32МБ
edo1
изменяются — переписываются целиком?
edo1
тогда это не имеет значения
edo1
тогда лучше делать recorsize побольше
edo1
как раз большой recordsize сделает фрагментацию менее вероятной
George
давайте на конкретике - у вас какой размер файла средний?
George
при чтении он полностью будет запрошен?
George
тогда есть смысл поставить recordsize=4M , чтобы файл всегда хранился одним куском
George
никакой фрагментации, главное чтобы успевали вычитать его из ARC до его вымывания оттуда
George
да, тут надо аккуратно проверить что вы точно за раз весь файл вычитываете/записываете всегда
George
если это не так, то recordsize=1M обычно норм
George
на hdd
George
+ сжатие уберёт проблему с последним блоком
George
конечно же, это стоит бенчить
George
но выигрыш весьма вероятен в вашем случае
George
при 5-10% изменений за день потихоньку само перезапишется)
George
если файлы пересоздаются
George
в ZFS большинство параметров при изменении на новые файлы действуют, ага
central
CoW фрагменимтирована by design
Δαρθ
плюс если сжатие не включено, и в файле больше одного блока, то последний блок будет полного размера с нулями
тогда значит все куски данных строго recordsize? даже обрубки в конце файла?
George
тогда значит все куски данных строго recordsize? даже обрубки в конце файла?
если у файла больше чем 1 блок - то да. Но сжатие позволяет последний блок сжать
Δαρθ
блин я наверное тупой :(
если сжатие выкл то файл 1.5мб с рекордсайз 1м займет 2мб
а если включено то в 1 рекордсайзе будет что? пусть например при этом файл не сжался до меньше 1м никак
George
блин я наверное тупой :(
если сжатие выкл то файл 1.5мб с рекордсайз 1м займет 2мб
а если включено то в 1 рекордсайзе будет что? пусть например при этом файл не сжался до меньше 1м никак
на сжатие всегда придут только данные одного блока
Олег
Решил тут детально мониторить ZFS на серверах. Кто чем мониторит? https://share.zabbix.com/operating-systems/zfs - оказался не рабочий, не сообразил как починить ошибку,root@voffice:~# /etc/zabbix/zfs.py
Traceback (most recent call last):
File "/etc/zabbix/zfs.py", line 153, in <module>
'vdevs': vdev_list(vdev_errors),
File "/etc/zabbix/zfs.py", line 87, in vdev_list
} for x in r if x[0].startswith('/')}
File "/etc/zabbix/zfs.py", line 87, in <dictcomp>
} for x in r if x[0].startswith('/')}
KeyError: '/dev/disk/by-id/ata-TOSHIBA_DT01ACA300_895BLKTAS-part3'
Roman
George
Можно
George
https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Module%20Parameters.html#zfs-max-recordsize
George
Просто параметр этот поправить надо осознанно
Eugen
Eugen
Правильно ли я понимаю? syncoid использует инструменты zfs send recv, но просто своими коммандами?
Evgenii
Правильно ли я понимаю? syncoid использует инструменты zfs send recv, но просто своими коммандами?
да, и все подобные тулзы
Eugen
понял, тогда и смысла в них нет.
Evgenii
есть
Evgenii
автоматизация
Evgenii
я писал километровый скрипт на баше лет 5 назад для этого
Evgenii
дерево датасетов обрабатывать
Evgenii
там много нюансов
Evgenii
Eugen
Через zfs send хоть получалось снимок отправить, им бы и пользовался, но не додумался еще как сделать так, что бы при следующей отправке, новый снимок заменил старый снимок на целевом сервере, при этом с целевого снимка уже сделано кучу клонов и они в работе 24/7.
Evgenii
мне кажется вы не понимаете что такое снимки
Eugen
Снапшот, что же еще
Evgenii
хорошо, тогда что значит один снапшот должен заменить другой?
Eugen
Да, но другой уже работает, то есть он родитель дерева на удаленном сервере, и по этому не даст себя удалить без удаления всего дерева, верно? Значит нужен способ просто тихо обновить данные на нем
Evgenii
да я не о вашей проблеме пока еще речь веду. А о том, что бы мы говорили на одном языке.
нельзя заменить один снимок другим - нет такой операции в природе. Это речевая конструкция не имеет смысла в разрезе снимков
Eugen
Хорошо, возможно такое можно сделать с клонами zvol, или на крайняк оригинальными наборами данных?
Eugen
Специфика сервера такая, есть несколько zvol, с которых лелаются клоны, и вот кооны раздаются клиентам
Eugen
Хочу сделать так что бы клоны раздавались с обного сервера множеству удаленных
Evgenii
по ssh реплицируете файловую систему, так? делаете снимок, и отправляете его на удаленный сервер. Там создается новая файловая система из снимка
Eugen
На удаленный пока только пробую с помощью zfs send recv, а там уже клонирую.
Evgenii
и что нужно дальше?
Eugen
То что работает сейчас, клонируется внутри каждого сервера, но это все затруднительнее с увеоичением числа таких серверов
Eugen
Врт был бы механизм отправки на удаленные сервера снимка или клона датасета с актуальеыми изменениями по несколько раз в день, а уже на удаленных серверах с этого клонировать клиентам.
Evgenii
* у вас есть "золотая" файловая система, которую вы периодически обновляете
* в делаете копии золотой файловой системы на другие сервера, чтобы люди запускали с них виртуальные машины
* вы хотите иметь способ "сбрасывать" все изменения на клиентских серверах и накатывать обновление с "gold"
так?
Eugen
Да, все верно
Evgenii
ну так бы сразу и написали.. не сложно же)
Eugen
При чем без обрыва работы клиентов.
Evgenii
а клиенты - контейнеры линукс? или виртуалки
Eugen
Виндус, раздаются по iscsi
Evgenii
я не понимаю как это можно сделать технически без обрыва в принципе, (без всякой привязки к ZFS)
Eugen
Сервер основан на фряхе
Evgenii
такое вообще возможно? с помощью каких то известных вам технологий. Если да, опишите подробно механизм. Возможно я смогу прикинуть как это сделать в ZFS
Eugen
В локальном сервере можно, но вот с удаленным не могу допереть как
Eugen
Есть золотой образ zvol, внутри него винда. Раздается по iscsi ipxe, в момент загрузки с ipxe дергается скрипт, который удаляет старый клон+снап, и создает новый с золотого образа. В итоге клиент получает диски с актуальной инфой.
Evgenii
а.. ну так это в момент перезагрузки клиента
Eugen
Да
Evgenii
я думал во время работы хотите..
Evgenii
путаете)
Eugen
Но клиенты не в один момент перезагружаются если что, рандомно
Evgenii
Но клиенты не в один момент перезагружаются если что, рандомно
у каждого клиента свой том. Тут нет технических ограничений тогда
Eugen
Вопрос как золотой образ подгонять с удаленного сервера, и клонировать на месте, а потом обновить его, и при чем так что бы работающие люди этого не ощутили
Evgenii
в скрипте сейчас жестко задано имя снимка с которого создается новый клон, поэтому вы употребляли фразу "заменить снимок другим"?
Eugen
Нет, я имел в виду замену клона/снимка на актуальный с удаленного (главного) сервера. И вот уже следующие клоны на клиентские пк делать с этого нового снимка/клона, пока не появится новый актуальный снимок с удаленного сервера
Evgenii
чтобы не запутаться - zfs clone работает только внутри одного zfs пула. То есть нельзя сделать клон на удаленную систему.
* вы отправите через zfs send копию файловой системы с основного сервера на удаленные сервера, указав определенный снимок.
* для "обновления" вы будете отправлять новые снимки с основного сервера на удаленные сервера. Точнее это будет команда zfs send -i имя_тома@исходный_снимок имя_тома@конечный_снимок | ssh root@ip zfs recv -v имя_тома
* когда ваш скрипт будет уничтожать клиентскую фс и снова клонировать ее из gold, он должен будет клонировать из последнего снимка.
* снимки можно удалять, если вам больше не нужно на них откатываться.
Eugen
Да, верно.
Evgenii
Evgenii
чтобы не запутаться - zfs clone работает только внутри одного zfs пула. То есть нельзя сделать клон на удаленную систему.
* вы отправите через zfs send копию файловой системы с основного сервера на удаленные сервера, указав определенный снимок.
* для "обновления" вы будете отправлять новые снимки с основного сервера на удаленные сервера. Точнее это будет команда zfs send -i имя_тома@исходный_снимок имя_тома@конечный_снимок | ssh root@ip zfs recv -v имя_тома
* когда ваш скрипт будет уничтожать клиентскую фс и снова клонировать ее из gold, он должен будет клонировать из последнего снимка.
* снимки можно удалять, если вам больше не нужно на них откатываться.
старые снимки gold тома на удаленных серверах можно будет удалять. Но они не смогут быть удалены, пока будет существовать хотя бы 1 клон - что логично. Как только все клиенты обновятся, удаление пройдет
Eugen
старые снимки gold тома на удаленных серверах можно будет удалять. Но они не смогут быть удалены, пока будет существовать хотя бы 1 клон - что логично. Как только все клиенты обновятся, удаление пройдет
Та в этом и бочина, был бы способ обновить инфу не удаляя все клоны.
Eugen
Разве что rsync