<![CDATA[Linux Forum — Леннарт Поттеринг представил свой новый проект Casync]]>2017-06-20T14:16:01ZPunBBhttps://linuxforum.ru/viewtopic.php?id=39287<![CDATA[Леннарт Поттеринг представил свой новый проект Casync]]> Леннарт Поттеринг (Lennart Poettering) анонсировал проект Casync, над которым он работал последние несколько месяцев. Casync позиционируется как эффективное средство для распространения образов файловых систем, оптимизированное для организации частых обновлений через интернет, в том числе поверх HTTP и CDN-сетей. Casync нацелен на предоставление оптимального метода хранения и доставки различных версий содержимого крупных файловых систем или каталогов. В настоящее время разработка Casync сосредоточена на оптимизации доставки прошивок для потребительских интернет-устройств, образов контейнеров и виртуальных машин, приложений, переносимых сервисов и различных образов операционных систем. В будущем возможности проекта будут расширены для таких задач как резервное копирование и синхронизация домашних каталогов. Код написан на языке Си и распространяется под лицензией LGPLv2.1. Поддерживается работа как на уровне блочного устройства (доставка содержимого дисков, образов ФС и блочных устройств), так и на уровне файловой системы (обработка содержимого каталогов). В качестве причины создания нового ПО упоминается отсутствие готового решения для эффективного распространения часто меняющихся образов ФС. Например, Docker оперирует многоуровневыми архивами и требует слишком много дисковых ресурсов для поддержания полной истории изменений; OSTree передаёт отдельные файлы по HTTP, требует много места для delta-изменений на сервере и имеет проблемы с CDN; поставка образов в виде готовых файловых систем squashfs или IS09660 неэффективна в точки зрения дисковых затрат и трафика. В итоге, изучив недостатки имеющихся решений, перед проектом Casync были поставлены следующие цели: Минимизация трафика при доставке образов с интенсивным циклом обновления (для решения данной задачи большинство существующих систем используют доставку дельта-изменений); Экономное использование дискового пространства на серверах (поддержание дельта-изменений для всех комбинаций версий приводит к экспоненциальному росту занимаемого дискового пространства); Экономное использование дискового пространства на стороне клиента; Адаптация для задействования сетей доставки контента (CDN) и загрузки поверх HTTP; Простой интерфейс для пользователей, администраторов репозиториев и разработчиков. Управление производится через утилиту командной строки casync, предоставляющей команды подобные "casync list http://www.foobar.com/lennart.caidx" и "сasync extract http://www.foobar.com/lennart.caidx /home/lennart". Для достижения поставленных задач Casync комбинирует алгоритмы передачи данных от проекта rsync с git-подобными средствами организации контенто-адресуемых хранилищ. Данные сохраняются в файле .castr, который представляет собой хранилище отрывков (chunk store), в котором большой линейный поток данных разбивается на отрывки (chunk) переменной длинны, которые сохраняются в виде отдельных сжатых файлов с именем, составляющим хэш SHA256 от содержимого этого файла. Таким образом имя файла выступает ключом для извлечения порции данных. Chunk store позволяет абстрагироваться от отдельных файлов - например, несколько мелких файлов будут объединены в один chunk, а большой файл разбит на несколько chunk-ов. При этом размер chunk-а варьируется и выбирается с учётом размера файлов для обеспечения дедупликации, т.е. если размер файла укладывается в допустимый диапазон размера chunk-ов, то он будет размещён в отдельном chunk-е. Хранилище дополняют два вида индексов (.caidx и caibx) и архив со структурой дерева каталогов (.catar). Индекс отрывков ("chunk index") содержит список хэшей отрывков и их размер, что позволяет выявлять идентичные отрывки и исключать сохранение дубликатов, что актуально при хранении нескольких версий данных. При обновлении клиент определяет недостающие кусочки и загружает только их. Содержимое дерева каталогов представлено в формате, обеспечивающем повторяемую сериализацию, т.е. упаковка одних и тех же данных всегда приводит к созданию идентичных архивов Casync, что позволяет применять расширенные схемы верификации. Источник: http://www.opennet.ru/opennews/art.shtml?num=46728