https://www.opennet.ru/openforum/vsluhforumID3/115238.html В рамках проекта Zero (https://github.com/KonstantinSchubert/zero) ведётся разработка экспериментальной многослойной файловой системы с реализацией идеи хранения данных в локальной ФС с вытеснением давно не используемых данных во внешнее облачное хранилище. Код предлагаемого для тестирования прототипа написан на языке Python, использует подсистему FUSE и поставляется (https://github.com/KonstantinSchubert/zero) под лицензией MIT.<br><br><br>Первый слой, размещаемый в локальной ФС, выступает в роли кэша, в котором доступны только актуальные данные. Таким образом, на базе ограниченного по размеру локального накопителя можно создать архивное хранилище существенно большего размера, выглядящее как одна целостная ФС. В настоящее время из облачных хранилищ поддерживается только сервис Backblaze (https://en.wikipedia.org/wiki/Backblaze).<br><br><br><br><br>URL: https://news.ycombinator.com/item?id=17948287<br>Новость: https://www.opennet.ru/opennews/art.shtml?num=49249<br> https://www.opennet.ru/openforum/vsluhforumID3/115238.html#167 Tue, 18 Sep 2018 14:54:26 GMT Кто такая ZFS я вроде знаю. С ее плюсами и минусами. Не подходит. Она используется сейчас как шустрое/рабочее хранилище.<br><br>&gt;именно так и есть, только без "облачков" (san сойдет тебе за "кластер"?) <br><br>Не сойдет - сложности с изменением размеров/надежностью и т.д.. :-(<br>Сейчас используется MooseFS под архив и бэкап. Позволяет динамически менять размер и надежность хранения в любую сторону.<br><br>По идее, хотелось бы верхним слоем, с которым оперативно работают - ZFS. А нижним MooseFs - под длительное хранение.<br><br>Только требуется автоматизацию телепортации. :-)<br><br><br><br> https://www.opennet.ru/openforum/vsluhforumID3/115238.html#166 Mon, 17 Sep 2018 07:52:43 GMT &gt; А аналоги какие-нибудь есть на чем угодно?<br><br>наша zfs с arc2<br><br>&gt; Сейчас приходится реализовывать вручную. Хотелось бы автоматизации. Лучше между точками <br>&gt; монтирования, но не блочными устройствами, как предлагают выше.<br><br>нет, такой фигней мы не страдаем<br>&gt; Т.к. с блочными проблем побольше....<br><br>у нас как-то не замечено.<br><br>&gt; А так есть: <br>&gt; фс на быстром диске - там актуальные данные <br>&gt; фс на медленном диске/кластере/облаке - там много место и надежно <br><br>именно так и есть, только без "облачков" (san сойдет тебе за "кластер"?) <br><br>для пользователя все прозрачно и быстро, для админа - zpool add...<br><br><br><br> https://www.opennet.ru/openforum/vsluhforumID3/115238.html#165 Mon, 17 Sep 2018 07:49:06 GMT &gt; Окей, мы знаем, что у пользователей U1 и U2 зашифрованные блоки B1 <br>&gt; и B2 имеют одинаковый sha512. Как теперь хранить только один из <br>&gt; этих блоков?<br><br>зачем? <br>Если ты каким-то чудом (например, нанятый вменяемый разработчик понимал, для чего на самом деле существуют криптографические хэши - чудо!) вовремя об этом узнал - просто сохраняешь второй блок отдельно от первого. Ровно так же, как в случае, если бы эти sha оказались разными (точнее "поиск хэша B2 ничего не нашел").<br><br>На момент, когда ты считал его хэш, он у тебя еще был, есть что сохранять.<br><br>внутри файла-то они не по хэшам ищутся, а банально по ссылке.<br><br>zfs dedup+verify примерно так и работает<br> https://www.opennet.ru/openforum/vsluhforumID3/115238.html#164 Mon, 17 Sep 2018 05:45:01 GMT &gt;Когда кодер меняет тип с int на short и вдруг все начинает передаваться в два раза быстрее<br><br>Какие фантазии. Напрямую TCP пакеты создаёшь? У нормальных пацанов по сети ходит XML over HTTP :D<br> https://www.opennet.ru/openforum/vsluhforumID3/115238.html#163 Sat, 15 Sep 2018 02:46:18 GMT Окей, мы знаем, что у пользователей U1 и U2 зашифрованные блоки B1 и B2 имеют одинаковый sha512. Как теперь хранить только один из этих блоков?<br> https://www.opennet.ru/openforum/vsluhforumID3/115238.html#162 Thu, 13 Sep 2018 11:35:04 GMT никак. авторы всех технологий дедапа верят, что коллизия хэшей невозможна.<br>Мысль о том, что по сути они заменяют блоки данных, предположим, в 128k, строкой в 256 бит - причем ВСЕ блоки неизвестного содержимого - ограниченным количеством строк (в зависимости от типа хэша может оказаться, что далеко не каждая строка - валидный хэщ чего бы то ни было) им, по-моему, в головы вообще не приходит, там некуда, там карри. Единственное исключение - zfs, там сановские инженеры еще головами думали, а не только ели - там есть verify, если не хочется проверять свое везение (разумеется, снижает скорость, но часто этим можно пожертвовать)<br><br>то есть по сути, да, на наших глазах переизобретается архиватор del, только уже в глобальном масштабе.<br><br>оно бы и работало, даже, в масштабах локалхостов, даже достаточно больших - но в масштабах амазона или бэкблейза вопрос коллизии - только вопрос времени.<br><br> https://www.opennet.ru/openforum/vsluhforumID3/115238.html#161 Thu, 13 Sep 2018 09:00:23 GMT А аналоги какие-нибудь есть на чем угодно? <br>Идея мне очень нравится.<br>Сейчас приходится реализовывать вручную. Хотелось бы автоматизации. Лучше между точками монтирования, но не блочными устройствами, как предлагают выше.<br><br>Т.к. с блочными проблем побольше....<br><br>А так есть:<br> фс на быстром диске - там актуальные данные<br> фс на медленном диске/кластере/облаке - там много место и надежно<br><br>Пользователю нужно прозрачно, по возможности работать быстро. Как такое сделать?<br> https://www.opennet.ru/openforum/vsluhforumID3/115238.html#160 Wed, 12 Sep 2018 23:55:46 GMT &gt; Да? А что делать при коллизии хэшей? Приехали?<br><br>Я не знаю, как эту проблему решили в borgbackup. Найдёшь - отпишись.<br> https://www.opennet.ru/openforum/vsluhforumID3/115238.html#159 Wed, 12 Sep 2018 21:50:08 GMT Еще бы. Даже и не знаю, реально ли вообще сделать бои подобного масштаба без тормозов. Наверное... все-таки нет.<br>