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

емнип всё ок должно быть, стрим не содержит инфы об vdevs

Каждая запись идет через транзакцию. До некоторого предела можно всегда откатиться назад. Но я бы на это не полагался а делал snapshot (я так и делаю). Снимок гарантированно заблокирует данные и они не будут удалены. Создается он мнгновенно, удаляется тоже мнгновенно на датасетах любого объема.

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

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

Как-то бы вытащить из ZFS максимум отчетных данных, которые ссылаются на идентификаторы в снэпшотах, которые трудно подделать (если такие есть). При дедупликации ведь включаются длинные хэши, это только для блоков данных? Для других более глобальных структур длинные хэши не включить?

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

ни в коем случае! только криптохеши, sha,blake,skein (и сомнительно -- edonr)

Считать сумму снэпшота? Это обсчитывать все его файлы? Я хотел штамповать просто какие-то отчетные структуры ZFS, которые выдаются почти мгновенно.

Как-то бы вытащить из ZFS максимум отчетных данных, которые ссылаются на идентификаторы в снэпшотах, которые трудно подделать (если такие есть). При дедупликации ведь включаются длинные хэши, это только для блоков данных? Для других более глобальных структур длинные хэши не включить?

стоимость вычисления прообраза криптохеша (т.е. подгонка данных под заданный хеш) -- это 2^n, где n - колво битов в хеше

У снимков есть скрытое уникальное свойство guid при копировании снимка через zfs send | zfs receive оно сохраняется.

Как-то бы вытащить из ZFS максимум отчетных данных, которые ссылаются на идентификаторы в снэпшотах, которые трудно подделать (если такие есть). При дедупликации ведь включаются длинные хэши, это только для блоков данных? Для других более глобальных структур длинные хэши не включить?

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

стоимость вычисления прообраза криптохеша (т.е. подгонка данных под заданный хеш) -- это 2^n, где n - колво битов в хеше

Еще и квантовые компьютеры не умеют ломать хэши, AFAIK ?

Почему скрытое? Оно ведь присутствует в выводе zfs get all ?

еслиб те еще и существовали....

Квантовые компьютеры - это фейк? :)

Может быть сейчкс что-то поменадось, но раньше я его искал и не было. Может быть я был не достаточно внимателен.

Квантовые компьютеры - это фейк? :)

Это не фейк, но пока угроза от них выглядит преувеличенной и есть хеши более устойчивые к квантовому взлому. У квантовых компьютеров есть другие ограничения.

просто для валидации целостности криптостойкость избыточна

Это не фейк, но пока угроза от них выглядит преувеличенной и есть хеши более устойчивые к квантовому взлому. У квантовых компьютеров есть другие ограничения.

какие например (хеши)?

Современные длинные хэши и так устойчивы к квантовому взлому, насколько я знаю. А вот например асимметричное крипто уже нет, RSA 2048 ломается за день, RSA 4096 за месяц, просто находил такое в сети. Сам я даже не понимаю, в чем суть работы таких квантовых компов и как они там чего-то ломают перебором якобы одновременным большим количеством состояний, для меня это за гранью понимания, особенно после обсуждения на LOR.

https://www.linux.org.ru/forum/talks/16885685

помоему рса2048 за день и без квантовых компов ломается )

Перебором в распределенной системе?

ну рса (факторизация числа на 2 простых множителя) точно не перебором ломается а, собственно, факторизацией

Современные длинные хэши и так устойчивы к квантовому взлому, насколько я знаю. А вот например асимметричное крипто уже нет, RSA 2048 ломается за день, RSA 4096 за месяц, просто находил такое в сети. Сам я даже не понимаю, в чем суть работы таких квантовых компов и как они там чего-то ломают перебором якобы одновременным большим количеством состояний, для меня это за гранью понимания, особенно после обсуждения на LOR.

Лучше во флуде такое обсуждать

Это не просто как два числа в конвертах. Чтобы не вывихнуть мозг можно руководствоваться многомировой интерпритацией эффектов квантовой нелокальности. Лучше всего самому раскурить тему, там нет ничего сложного. Если вдуматься, тотв е эти квантовые парадоксы всего лишь ограничения нашего опыта и мышления бвтовыми взаимодействиями с физическим миром. По сути это проявление законов сохранения, над полным смыслом которых мы сильно не задумываемся. Но результаты интересные, особенно в квантовой радиофотонике. Там чувствительность радаров подняли на магическую высоту.

Современные длинные хэши и так устойчивы к квантовому взлому, насколько я знаю. А вот например асимметричное крипто уже нет, RSA 2048 ломается за день, RSA 4096 за месяц, просто находил такое в сети. Сам я даже не понимаю, в чем суть работы таких квантовых компов и как они там чего-то ломают перебором якобы одновременным большим количеством состояний, для меня это за гранью понимания, особенно после обсуждения на LOR.

В личке могу попытаться объяснить :-)

CAP теорему и т.п.

От задачи зависит, я думаю: связано с zfs - можно :-) А какая задача? Для чего это нужно изучать?

Можно ли здесь обсуждать распределенные системы?

В рамках сабжа - да, остальное - во флуд.

Там в целом про распределенные системы и про СУБД в частности, еще LDAP, DNS, etc.

Перенесите лучше диалог во флуд или в личку.

Так во флуде ведь участники частично другие? Будет потеря ценных мнений и нападки DS :(

В рамках сабжа - да, остальное - во флуд.

Тем не менее.

что за флуд?)

что за флуд?)

Она сейчас по инвайтам, но Саша в ней есть

В моём случае СУБД ещё и в докер контейнере, и это сильно усложняет положение

В моём случае СУБД ещё и в докер контейнере, и это сильно усложняет положение

А кто-нибудь делал DR для БД postgresql с помощью zfs send? Понятно что это кривое решение, но хотелось бы понять на сколько