Всем привет, есть ли в zfs опция для синка файловых систем на подобии rsync?

Всем привет, есть ли в zfs опция для синка файловых систем на подобии rsync?

send / receive

send / receive

ну это очень грубый метод. Нужно синкать .img образ лежащий на пуле локальном и удаленном. Внутри образа NTFS. И хотелось бы не с полной заменой а только тех кусков что отличаются

ну это очень грубый метод. Нужно синкать .img образ лежащий на пуле локальном и удаленном. Внутри образа NTFS. И хотелось бы не с полной заменой а только тех кусков что отличаются

Так там дифы и летят

Снепшот и сенд

Так там дифы и летят

этот способ вроде не совместим с клонами системы которую будем менять. ТО еть пока есть клоны изменить не получится

Всем привет, есть ли в zfs опция для синка файловых систем на подобии rsync?

sanoid/syncoid Для консистентности конечно стоит сначала делать fsfreeze через гостевого агента вм, например, и только потом снимок и перегон на соседний хост. Но возможно и без этого Ваша задача будет решена. Если в качестве хостовой системы что-то вроде proxmox - вопрос решается на порядок проще.

Но под капотом там тот же снапшот и сенд, просто часть геморроя вокруг этого мероприятия на себя заберет подобное решение.

sanoid/syncoid Для консистентности конечно стоит сначала делать fsfreeze через гостевого агента вм, например, и только потом снимок и перегон на соседний хост. Но возможно и без этого Ваша задача будет решена. Если в качестве хостовой системы что-то вроде proxmox - вопрос решается на порядок проще.

Машины раздают клоны оригинальных образов клиентам с помощью iscsi. Получится ли изменить оригинальный образ не убивая клоны? Просто знаю что в зфс надо обязательно избавится от клонов и только потом что то делать с фс

Машины раздают клоны оригинальных образов клиентам с помощью iscsi. Получится ли изменить оригинальный образ не убивая клоны? Просто знаю что в зфс надо обязательно избавится от клонов и только потом что то делать с фс

Получится, т.к клон не делается не датасета, а снимка. И есть операция promote, с помощью которой можно перенести заблокированеый клоном снимок в люьой из клонов.

Получится, т.к клон не делается не датасета, а снимка. И есть операция promote, с помощью которой можно перенести заблокированеый клоном снимок в люьой из клонов.

А если версии зфс разные не много?

https://habr.com/ru/company/ruvds/blog/681158/

Эх жизнь моя жестянка чтоб я на ссд бэкапы хранил

https://habr.com/ru/company/ruvds/blog/681158/

Интересно, сколько живет ssd, если его ресурс перезаписи далёк

Эх жизнь моя жестянка чтоб я на ссд бэкапы хранил

Очень бессмысленная затея )) особенно в отсутствии питания на эти ссд)

https://habr.com/ru/company/ruvds/blog/681158/

Ставить ssd разных вендоров в каждый вдев? Ну чтоб ресурс различался и не одновременно вылетели

https://habr.com/ru/company/ruvds/blog/681158/

Это ж не про всех вендоров вроде. Такая "фича" была у hp, за остальных вроде не писали. И то лечилось прошивкой

Прошивать десяток другой дисков тоже то удовольствие ((

Это ж не про всех вендоров вроде. Такая "фича" была у hp, за остальных вроде не писали. И то лечилось прошивкой

В статье первым про SanDisk написали)

Это ж не про всех вендоров вроде. Такая "фича" была у hp, за остальных вроде не писали. И то лечилось прошивкой

Это проблема в прошивке производителе. Dell, cisco, hpe открыто заявили что обновитесь

Но положили болт люди

помню в детстве меня один дизайнер мучал что его его комп медленно работает. Мы утверждали что нефиг в фотошопе одновременно 7 гиговых проектов открывать, а он говорил что дома у него всё летает. Парировали что что у него "самый быстрый и новый" комп на диком западе на h61 и i5... В общем я и представить не мог что в россию проникли материнские платы с дефектными чипами h61(спустя некоторое время деградировал порт SATA) и мне выпадет счастье их купить спустя примерно 8(!) месяцев после того как интел заявил о фиксе проблеме.

и после перетыка порта - его фотошоп залетал буквально, в разы быстрее

Ну это ещё более менее легко поймать и диагностировать

Я как-то наткнулся на парковки головок в новых wd дисках каждые 10 сек

Благо сразу смарт посмотрел после включения, а так бы оставил - а они нарабатывают себе парковки 24/7 😔

Машины раздают клоны оригинальных образов клиентам с помощью iscsi. Получится ли изменить оригинальный образ не убивая клоны? Просто знаю что в зфс надо обязательно избавится от клонов и только потом что то делать с фс

у меня работает так есть образ, который синхронизируется по send|receive инкрементально с него периодически делаются снапшоты, со снапшотов клоны наличие снапшотов и клонов никак не влияет на обновление оригинала, если вы сами на оригинале не делали снапшотов, а для создания клонов используете снапшоты от send|receive

еще вопросик, ткните плз на патч для nvme

еще вопросик, ткните плз на патч для nvme

в мастере есть

конечно https://github.com/openzfs/zfs/pull/10018

^

@DedUndead

@DedUndead

оп, благодарю)

в мастере есть

Разве?

Разве?

@gmelikov точно может сказать

@gmelikov точно может сказать

Так я его комментарий и линканул

@gmelikov точно может сказать

Не в мастере

Я дошёл до этапа подключения по сетке. ZFS: zpool create -o ashift=12 -O compression=lz4 -O atime=off -O recordsize=64k nvme /dev/nvme0n1 /dev/nvme1n1 /dev/nvme3n1 -f zfs create -s -V 2.7T -o volblocksize=64k -o compression=lz4 nvme/iser fio -name=rndw4k16 -ioengine=libaio -direct=1 -buffered=0 -invalidate=1 --runtime=100 --time_based=1 -numjobs=4 -bs=64k -iodepth=32 -rw=randwrite -filename=/dev/mapper/mpat WRITE: bw=916MiB/s (960MB/s), 229MiB/s-229MiB/s (240MB/s-240MB/s), io=54.1GiB (58.0GB), run=60460-60460msec mdadm: fio -name=rndw4k16 -ioengine=libaio -direct=1 -buffered=0 -invalidate=1 --runtime=100 --time_based=1 -numjobs=1 -bs=64k -iodepth=32 -rw=randwrite -filename=/dev/mapper/mpathd WRITE: bw=1748MiB/s (1833MB/s), 1748MiB/s-1748MiB/s (1833MB/s-1833MB/s), io=121GiB (130GB), run=71062-71062msec

Да, iSER мне нравится больше iSCSI mdadm - 40G (1 link) - fio io=32, bs=1M&64k ___________ fio -name=rndw4k16 -ioengine=libaio -direct=1 -buffered=0 -invalidate=1 --runtime=10 --time_based=1 -numjobs=1 -bs=1M -iodepth=32 -rw=randread -filename=/dev/sdb randREAD: bw=4617MiB/s (4841MB/s), 4617MiB/s-4617MiB/s (4841MB/s-4841MB/s), io=45.1GiB (48.4GB), run=10007-10007msec ___________ fio -name=rndw4k16 -ioengine=libaio -direct=1 -buffered=0 -invalidate=1 --runtime=10 --time_based=1 -numjobs=1 -bs=1M -iodepth=32 -rw=randwrite -filename=/dev/sdb randWRITE: bw=4452MiB/s (4669MB/s), 4452MiB/s-4452MiB/s (4669MB/s-4669MB/s), io=43.5GiB (46.7GB), run=10008-10008msec ___________ fio -name=rndw4k16 -ioengine=libaio -direct=1 -buffered=0 -invalidate=1 --runtime=10 --time_based=1 -numjobs=1 -bs=64k -iodepth=32 -rw=randread -filename=/dev/sdb randREAD: bw=2826MiB/s (2963MB/s), 2826MiB/s-2826MiB/s (2963MB/s-2963MB/s), io=27.6GiB (29.6GB), run=10001-10001msec ___________ fio -name=rndw4k16 -ioengine=libaio -direct=1 -buffered=0 -invalidate=1 --runtime=10 --time_based=1 -numjobs=1 -bs=64k -iodepth=32 -rw=randwrite -filename=/dev/sdb randWRITE: bw=2526MiB/s (2649MB/s), 2526MiB/s-2526MiB/s (2649MB/s-2649MB/s), io=24.7GiB (26.5GB), run=10001-10001msec ___________ Теперь я жду патча io_direct на zfs ещё больше multipath однако не даёт значительно выше результаты, даже при round-robin & rr_min_io=1 (512k блоки): один путь - READ: bw=4637MiB/s (4862MB/s), 4637MiB/s-4637MiB/s (4862MB/s-4862MB/s), io=45.3GiB (48.6GB), run=10004-10004msec два пути - READ: bw=5117MiB/s (5366MB/s), 5117MiB/s-5117MiB/s (5366MB/s-5366MB/s), io=49.0GiB (53.7GB), run=10004-10004msec

Очень неплохо

Смысла в 512 форматировать нвме вроде как давно уже нет. Коллеги, поправьте, если ошибаюсь.

очень даже есть есть почти все файлы планируются супер маленького размера

Оке, буду ручками запускать fstrim. В остальном, норм?

на zfs - не fstrim, а zpool trim $tank

подскажите, столкнулся с сценарием, когда на zfs датасете удалили много-много файлов, и даже спустя какое-то время используемая quota не уменьшилась. Гугл подсказывает, что в ряде случаев раньше что-то могло пойти не так, и подопнуть очередь на удаление можно через ремаунт, но сервер с тех пор перезагружался, так что ремаунт уже происходил. Что посмотреть, что можно сделать? Поможет ли scrub ?

очень даже есть есть почти все файлы планируются супер маленького размера

Так сейчас же везде 4к формат? Вы со своим 512 получите падение перфоманса при записи из-за read-mod-write физических 4к блоков

Так сейчас же везде 4к формат? Вы со своим 512 получите падение перфоманса при записи из-за read-mod-write физических 4к блоков

получу ли? ) Маленькие файлики пишутся один раз, читаются много. Большие файлики запишутся в рекордсайзы и будут относительно выровнены NVMe умеет скорости в 2+ гигабайта на запись в секунду, реальная нагрузка почти никогда не такова

а если серьезно, то практические тесты на том железе, что есть у меня, принципиальное снижение скорости не показывает.

но все от задачи зависит, конечно

Смысла в 512 форматировать нвме вроде как давно уже нет. Коллеги, поправьте, если ошибаюсь.

Меня ткнули в результаты которые на 512 быстрее, не мотря на то что 4096 формат помечен как максимальной производительности.

Меня ткнули в результаты которые на 512 быстрее, не мотря на то что 4096 формат помечен как максимальной производительности.

это про nvme format, вероятно. У нас на intel p4510 тоже фактически при форматировании в 512 они быстрее, примерно на 3%

это про nvme format, вероятно. У нас на intel p4510 тоже фактически при форматировании в 512 они быстрее, примерно на 3%

А pmem не практиковали ?

Даже если брать app direct режим, то все равно быстрее чем nvme.

А pmem не практиковали ?

Нет, не было возможности

подскажите, столкнулся с сценарием, когда на zfs датасете удалили много-много файлов, и даже спустя какое-то время используемая quota не уменьшилась. Гугл подсказывает, что в ряде случаев раньше что-то могло пойти не так, и подопнуть очередь на удаление можно через ремаунт, но сервер с тех пор перезагружался, так что ремаунт уже происходил. Что посмотреть, что можно сделать? Поможет ли scrub ?

а чисто теоритически: сколько занято в датасете и каков размер квоты?

102гб занято по квоте зфс, 92 по файлам по мнению df

102гб занято по квоте зфс, 92 по файлам по мнению df

еденицы измерения одинаковые?

Да

102гб занято по квоте зфс, 92 по файлам по мнению df

снапшоты есть?

Это первое что проверил )

Нету

файлы мелкие?

Очень

Менее 512 байт почти все

Очень

значит скорее всего оверхед на хренение или на размер блока

а размер recordsize какой

100 гиговый датасет?🤔

а размер recordsize какой

16к

16к

ну вот и ответ

Ашифт то 9

Ашифт то 9

и что должно с этим происходить?

Если файл меньше - он запишется в меньше

либо у меня знаний мало либо у тебя их больше чем у меня

рекордсайз - это максимальный размер записи, а не минимальный

рекордсайз - это максимальный размер записи, а не минимальный

да, верно. но все равно я думаю у тебя оверхед именно на мету

тем временем scrub таки решил проблему...

или параллельно ему произошла еще какая-то магия

все телепаты в чате собрались и коллективным воздействием бессознательного на твои блины решили проблему

да, верно. но все равно я думаю у тебя оверхед именно на мету

я плохо помню как зфс всё хранит, но кажется супермелкие файлы могут храниться вместе с метадатой вообще в том, что у зфс аналог иноды

самая крутая фс

как гарантируется что переданный в другое место снапшот не попортился? для локальных данных есть чексуммы, защищают от случайной порчи на диске. а для send/recv какие механизмы? например если в процессе обработки данных на машине (1ой или 2ой) или в канале передачи случайная ошибка -- это задетектится? а есть ли метод сравнить данные на источнике и приемнике средствами zfs, чтобы убедиться что случайные ошибки ничего не попортили?

как гарантируется что переданный в другое место снапшот не попортился? для локальных данных есть чексуммы, защищают от случайной порчи на диске. а для send/recv какие механизмы? например если в процессе обработки данных на машине (1ой или 2ой) или в канале передачи случайная ошибка -- это задетектится? а есть ли метод сравнить данные на источнике и приемнике средствами zfs, чтобы убедиться что случайные ошибки ничего не попортили?

scrub?

как гарантируется что переданный в другое место снапшот не попортился? для локальных данных есть чексуммы, защищают от случайной порчи на диске. а для send/recv какие механизмы? например если в процессе обработки данных на машине (1ой или 2ой) или в канале передачи случайная ошибка -- это задетектится? а есть ли метод сравнить данные на источнике и приемнике средствами zfs, чтобы убедиться что случайные ошибки ничего не попортили?

Наверн надо создавать потери на сети и по ней передавать снапшот

Вы что-то странное пишете