Cotton не хранит файлы как отдельные объекты в пользовательских директориях. Видимые файлы собираются из контентно-адресуемых чанков, манифестов и метаданных раскладки — поэтому дедупликация, возобновляемая загрузка, снимки, восстановление и очистка живут в одной модели.
Каждый физический чанк контента адресуется своим хешем. Хеш — не наклейка после записи, а ключ, по которому модель хранилища понимает, существует ли такой контент и можно ли его переиспользовать.
Видимый файл ссылается на манифест, а манифест описывает упорядоченные чанки и свойства файла. Поэтому файл может быть большим, перематываемым, пригодным для превью, версионируемым, расшаренным и восстанавливаемым, не превращаясь в один хрупкий блоб.
Пользовательское дерево хранится как метаданные раскладки и узлов. Дерево папок — лёгкие метаданные поверх стабильных ссылок на контент, так что копирование, снимки, восстановление, корзина и сценарии версионирования не переписывают каждый физический байт.
Дедупликация экономит реальное место на многопользовательских инстансах, но не должна слишком много светить таймингом. Cotton может отделять физическую дедупликацию от видимого пользователю поведения, чтобы уменьшить очевидные сигналы о существовании данных между пользователями.
Хранилище на файловой системе сегментирует ключи-хеши по путям каталогов, а S3-совместимое хранилище использует ту же логическую идентичность объекта. Верхним слоям не важно, упали ли байты на локальный диск или в объектное хранилище.
Чанк можно удалить только когда база данных говорит, что ни одна живая функция больше на него не ссылается. Снимки, превью, артефакты бэкапов, версии, шары и активные манифесты требуют явных путей хранения.
Модель конкретна: клиенты загружают чанки SHA-256, манифесты описывают упорядоченные списки чанков, записи раскладки описывают, где видны файлы, а очистка ждёт граф ссылок, прежде чем освободить физический контент.
Cotton проще доверять, потому что модель хранилища объясняет продукт. Дедупликация, возобновление, превью, снимки, восстановление и целостность — не отдельные трюки, а следствия идентичности контента.
Контентно-адресуемое хранилище явнее, чем простая обёртка над папкой. Cotton должен держать ссылки в базе данных, фоновую проверку и сборку мусора в порядке, потому что видимое дерево и физические байты разделены.
Оно даёт стабильную модель идентичности для дедупликации, возобновляемых загрузок, проверок целостности, снимков и безопасной очистки. Чем больше данных и пользователей, тем важнее эта база.
Нет. Контентная адресация идентифицирует логический контент. Cotton всё равно пишет сохраняемые данные через потоковый конвейер шифрования перед сохранением.
Да. Бэкенды на файловой системе и S3-совместимые могут использовать те же логические идентичности чанков, пока Postgres остаётся источником истины для живых ссылок и метаданных раскладки.