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

Я так понял шифрование чтобы целостность данных обеспечить

zfs сам проверяет целостность потока

Я так понял шифрование чтобы целостность данных обеспечить

Шифрование для спокойствия. Всё же обычно чужие данные через открытую сеть передаем. Шифрование не нужно если делать через ssh но это медленнее

zfs сам проверяет целостность потока

Спасибо

Тогда вы получите sustained производительность и энтерпрайзы покажут, кто тут папа

Шифрование для спокойствия. Всё же обычно чужие данные через открытую сеть передаем. Шифрование не нужно если делать через ssh но это медленнее

Да, через ссш это вечность

Да, через ссш это вечность

Я бы не сказал. До 300...500 мегабит разница не особенно заметна. Причем ssh можно попросить передавать данные с соответсвующин QoS

Если быть точным: ...send | pv --size 20G | lz4c -z | aespipe | mbuffer -q | nc -lp 10555 -q 1 На приемнике ` nc source_host 10555 -q 1| mbuffer | aespipe l lz4c -d | zfs receive ...

а если связь порвётся в момент передачи, это потом возобновиться с места разрыва или заново пойдёт тащить?

Так я о том и говорю, при размере в 8г картинка яснее

Если хотите понять, какова будет реальная производительность ssd под нагрузкой, рекомендую ezfio, но он деструктивный

а если связь порвётся в момент передачи, это потом возобновиться с места разрыва или заново пойдёт тащить?

Так zfs receive -s Возобновление возможно через токен которые берется с destanation датасета

Так zfs receive -s Возобновление возможно через токен которые берется с destanation датасета

а как об этом zfs send узнает чтобы не слать с самого начала?

а если связь порвётся в момент передачи, это потом возобновиться с места разрыва или заново пойдёт тащить?

Кстати, по этому я использую ssh - скрипты упрощаются. Щас на примере покажу

а как об этом zfs send узнает чтобы не слать с самого начала?

Как то договаривается с дестинешеном через токен)

Кстати, по этому я использую ssh - скрипты упрощаются. Щас на примере покажу

Кстати, есть где мануал по этой теме? Очень актуально, между серверами особенно автоматизировать данный процесс

Будем пробовать, спасибо. Отпишусь

а вы не пробовали распилить файл на несколько частей и параллельно несколько rsync делать?

а вы не пробовали распилить файл на несколько частей и параллельно несколько rsync делать?

На том конце не будет никто этот zvol пилить )) и места лишних нет 18тб

Как то договаривается с дестинешеном через токен)

понял, они в процессе передачи друг другу шлют подтвержение. Типа rsync, но на уровне самого zfs

а вы не пробовали распилить файл на несколько частей и параллельно несколько rsync делать?

Только что с примерами обсуждали через split и syncining или torrent sync

На том конце не будет никто этот zvol пилить )) и места лишних нет 18тб

понял

главное, чтобы места под снапшот для переноса хватило

главное, чтобы места под снапшот для переноса хватило

У меня 30тб пул

тогда нормально

Всем спасибо, завтра утром буду пробовать, о результатах отпишусь

понял, они в процессе передачи друг другу шлют подтвержение. Типа rsync, но на уровне самого zfs

Берем датасет root@htz-vm00 ~ # zfs send -nP zfs-ssd-big/local/proxmox/vm-421-disk-2@backup-2020.09.22-11.55 full zfs-ssd-big/local/proxmox/vm-421-disk-2@backup-2020.09.22-11.55 89590497976 size 89590497976 Посылаем его через пайп, для простоты локально через pv и прерываем через ^C root@htz-vm00 ~ # zfs send zfs-ssd-big/local/proxmox/vm-421-disk-2@backup-2020.09.22-11.55 | pv --size 89590497976 | zfs receive zfs-ssd-big/resume_test -s ^C.4GiB 0:00:21 [ 537MiB/s] [======> ] 12% ETA 0:02:27 И теперь у нас на destenation появился параметр: zfs get all zfs-ssd-big/resume_test zfs-ssd-big/resume_test receive_resume_token 1-1196b77aaf-e8-789c636064000310a500c4ec50360710e72765a5269740f80cd8e4d3d28a5381f20c0e363b98a0f26c48f2499525a9c540baa088611d1316fd25f9e9a599290c0c530b4ed4ba0628bc8d4092e704cbe725e6a6323054a515eb1617a7e82665a6ebe7e42727e6e81714e557e4e657e897e5ea9a1819eaa6641667eb1a39242526679716e81a191819e81958ea1919e91a1aea999a82dd0e0060ab27c8 - Проверяем сколько осталось: ``` zfs send -nP -t "1-1196b77aaf-e8-789c636064000310a500c4ec50360710e72765a5269740f80cd8e4d3d28a5381f20c0e363b98a0f26c48f2499525a9c540baa088611d1316fd25f9e9a599290c0c530b4ed4ba0628bc8d4092e704cbe725e6a6323054a515eb1617a7e82665a6ebe7e42727e6e81714e557e4e657e897e5ea9a1819eaa6641667eb1a39242526679716e81a191819e81958ea1919e91a1aea999a82dd0e0060ab27c8" resume token contents: nvlist version: 0 object = 0x1 offset = 0x2b83c4000 bytes = 0x2ae007270 toguid = 0xed2050457dc87095 toname = zfs-ssd-big/local/proxmox/vm-421-disk-2@backup-2020.09.22-11.55 full zfs-ssd-big/local/proxmox/vm-421-disk-2@backup-2020.09.22-11.55 78081298504 и продолжаем передачу root@htz-vm00 ~ # zfs send -t "1-1196b77aaf-e8-789c636064000310a500c4ec50360710e72765a5269740f80cd8e4d3d28a5381f20c0e363b98a0f26c48f2499525a9c540baa088611d1316fd25f9e9a599290c0c530b4ed4ba0628bc8d4092e704cbe725e6a6323054a515eb1617a7e82665a6ebe7e42727e6e81714e557e4e657e897e5ea9a1819eaa6641667eb1a39242526679716e81a191819e81958ea1919e91a1aea999a82dd0e0060ab27c8" | pv --size 78081298504 | zfs receive zfs-ssd-big/resume_test -s ^C82GiB 0:00:12 [ 480MiB/s] [===> ] 8% ETA 0:02:17 Я прервал еще раз и теперь токен поменялся zfs get receive_resume_token zfs-ssd-big/resume_test NAME PROPERTY VALUE SOURCE zfs-ssd-big/resume_test receive_resume_token 1-12bba4d398-e8-789c636064000310a500c4ec50360710e72765a5269740f80cd8e4d3d28a534b40329b8c58a0f26c48f2499525a9c540dae249b11a0b16fd25f9e9a599290c0c530b4ed4ba0628bc8d4092e704cbe725e6a6323054a515eb1617a7e82665a6ebe7e42727e6e81714e557e4e657e897e5ea9a1819eaa6641667eb1a39242526679716e81a191819e81958ea1919e91a1aea999a82dd0e0043e527a1 - ```

Я запутался в тегах, надеюсь принцип ясен.

Токен как видите действительно длинный

Токен как видите действительно длинный

вы его вручную указываете при повторном запуске zfs send?

понял, они в процессе передачи друг другу шлют подтвержение. Типа rsync, но на уровне самого zfs

нет, zfs send и recv односторонние

один тупо срёт в stdout, другой тупо читает из stdin

нет, zfs send и recv односторонние

я думал что там подобие rsync. Но тут вручную приходится токены указывать при обрыве. При наличии свободного места проще rsync сделать и на месте принять zvol.

т.е. если сильно захотеть - можно каждый второй мегабайт по другому коннекшену слать и собирать потом) но видать такого не делали за ненадобностью

т.е. если сильно захотеть - можно каждый второй мегабайт по другому коннекшену слать и собирать потом) но видать такого не делали за ненадобностью

ну вот я надеялся, что так кто-то придумал и реализовал))

ну вот я надеялся, что так кто-то придумал и реализовал))

увы, я быстрым гуглежом не нашёл)

inverse multiplexer типа

Ну не генеально конечно, но тему pipe-ов я действительно "прохавал", часто пользуюсь. Ещё раз напишу, что есть lz4 арх ватор (liblz4-tool) он почти не нагружает проц и может сжимать потоки на г габитных скоростях. Даже он даёт большой выигрышь по вре ени. Но если у вас очень много ядер (amd epyc например), можно исполтзовать pbzip2 -9 - это дас экономию в разы. Шифровприе musthave

еще вопрос, а pbzip2 нужно с ключом -c запускать, чтобы он в stdout срал?

Ну чисто технически можно делать скрипт который запросит текущий токен на дстнейшне и подставит в команду сенд

Хм блин а это идея

И в кого я такой умный 😂

Надо будет сделать

Надо будет сделать

делай )

делай )

Угу

Ну чисто технически можно делать скрипт который запросит текущий токен на дстнейшне и подставит в команду сенд

Куча решений уже, если что

Куча решений уже, если что

😭😭😭

Syncoid zfsnap zrepl

я думал что там подобие rsync. Но тут вручную приходится токены указывать при обрыве. При наличии свободного места проще rsync сделать и на месте принять zvol.

Я его в ручную не указываю, я использую скрипт. Не проще rsync: консистентность сников - раз, rsync будет читать все 20+TB перед возобновление передачи с двух сторон. Этот механизм проще, надёжнее и робастее. Но в ручную и вправду не очень удобно. Но как сделать лучше, я ума не приложу. По моему, это идеальное решение.

Куча решений уже, если что

А ссылочку? Ну или опыт. Я вот все пилю сам. Понимаю, что велосипедостроением занимаюсь, но что делать. Зато я хорошо знаю свойства своих решений.

Syncoid zfsnap zrepl

Спасибо!

А подскажите как быть с зашифрованными датасетами. Просто так инкремент не докидывается.

А подскажите как быть с зашифрованными датасетами. Просто так инкремент не докидывается.

вот я первый снапшот отправил zfs send -wv .. | zfs receive .. а потом zfs send -iwv не понимает что я хочу, а просто zfs send -i хочет от меня ключ для расшифровки.

за это время передалось бы уже, мне кажется

да, но мне же нужно понять как работать с шифрованным датасетом. а то вместо передачи пары гигов каждый раз передавать 200-300 не очень хочется.

@gmelikov, привет. вроде бы, шифрованные инкременталки должны работать?

@gmelikov, привет. вроде бы, шифрованные инкременталки должны работать?

по памяти - должны, не помню ограничений

@simubishi собирай стенд, тестируй :D

на свежих версиях

да, но мне же нужно понять как работать с шифрованным датасетом. а то вместо передачи пары гигов каждый раз передавать 200-300 не очень хочется.

а ты отправляешь без ключа на той стороне? этот кейс я ни тестил, ни смотрел, честно говоря))

на свежих версиях

не готов выходить из зоны комфорта :D все что выходит за пределы тестовой репы дебиана - не для меня )

а ты отправляешь без ключа на той стороне? этот кейс я ни тестил, ни смотрел, честно говоря))

приём без ключа

тогда рсинком :D

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

приём без ключа

а тебя recv о пароле спрашивает чтоли?

короч -i надо отделить от vw

тогда робит )

короч -i надо отделить от vw

💪

вот блин, проигнорил очевидное

вот блин, проигнорил очевидное

Кстати, шифрование на скорости сильно сказывается?

Кстати, шифрование на скорости сильно сказывается?

бенчей не делал, но на глаз незаметно

Кстати, шифрование на скорости сильно сказывается?

Я делал бенчи и на ссд и на хдд, пул рейд 10 - разницей можно пренебречь, она в пределах погрешности, нагрузка на ЦП растет минимально. Но я тестировал только lz4

Так что я включаю lz4 обязательно.

К слову в некоторых местах после включения наблюдал повышение производительности, но в каких уже не вспомню.

К слову в некоторых местах после включения наблюдал повышение производительности, но в каких уже не вспомню.

Это про компрессию. Но и шифрование на современеых просессорах с AES_NI не должно что-то ухудшать. Я бенчей не делал, но ни zfs-шифрование ни LUKS у меня заметного эффекта на производительность не оказывали.

Бля сорян. Чето я тупанул.реально читаю шифрование а думаю про сжатие. Надо заканчивать работать :)

Господа, сорри за вопрос, ответ на который можно найти в гугле, но всё, что я нахожу выглядит несколько противоречиво. Нужно экспертное мнение

В случае использования zfs on linux, работает ли нативное расшаривание zfs-пулов? Без использования samba, только силами zfs? Если да - то где почитать корректную доку? Если нет - где можно почитать про корректное расшаривание zfs-пулов через samba и nfs? Настройку юзеров, прав и т.п.

Я долго мучил zfs-ную доку от оракла, но видимо в случае zol она не особо актуальна. Или руки мои кривы Или proxmox в своём дистрибутиве намутил каких-то тонкостей.

Сценарии использования шареных пулов следующие - общая файловая шара для windows-систем (причем желательно видеть в "теневых копиях" снимки zfs), nfs и samba-шары для линуксовых хостов (общее хранилище кластера, хранение "дисков" виртуалок, вольюмы докеров и бэкапы)

В случае использования zfs on linux, работает ли нативное расшаривание zfs-пулов? Без использования samba, только силами zfs? Если да - то где почитать корректную доку? Если нет - где можно почитать про корректное расшаривание zfs-пулов через samba и nfs? Настройку юзеров, прав и т.п.

если речь про свойство smbshare, то я бы рекомендовал им не пользоваться, там есть ограничения, проще самому самбу по классике настроить как на любой другой ФС. Всё равно оно не "нативное", а использует ту же самбу и nfs, только настраивает через себя. Настройка снимков примерно так делается https://github.com/zfsonlinux/zfs-auto-snapshot/wiki/Samba#configure-samba

smbshare/nfsshare видел хорошую причину только одну использовать - когда нужно настройки таскать в пуле, например на другой сервер через zfs send

Огонь, спасибо огромное. Т.е. насколько я понимаю, корректный сценарий следующий - создаем сабвольюм на zfs пуле, ставим на хост samba, выдаем пермишны системному юзеру на этот сабвольюм, шарим самбой. Верно?