Как Cotton хранит файл. От браузера до диска.

Форма загрузки

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

• Идентичность чанка строится на SHA-256.
• Манифест файла собирает упорядоченные чанки в видимый контент.
• Прерванная загрузка досылает только то, чего не хватает.

Модель хранилища

Cotton отделяет граф раскладки от сохранённого контента. Видимый файл — абстракция поверх манифестов и чанков, опирающаяся на базу данных, а не один отдельный объект в пользовательской папке. Папки, узлы, версии файлов, снимки, манифесты и чанки имеют свои роли, поэтому навигация, восстановление, дедупликация и очистка становятся предсказуемыми.

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

Контракт бэкенда

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

• Публичный хеш чанка — это идентичность в хранилище.
• Объекты в бэкенде не раскрывают пользовательское дерево папок.
• База данных остаётся источником истины для живых ссылок.

Конвейер преобразования

Данные сжимаются до шифрования и потом пишутся в хранилище на файловой системе или поверх S3. Сжатие, шифрование и сохранение в бэкенде — не опциональные довески, а обычный путь приёма на потоковых буферах, без загрузки объекта целиком.

• Встроенный Zstd держит экономию места прямо на горячем пути.
• Потоковый AES-GCM аутентифицирует контент по чанкам.
• Бэкенды на файловой системе и S3 делят один логический конвейер.

Модель выдачи

Чтения собираются из чанков в поток байтов без пересборки файла целиком. Поэтому скачивания, превью, перемотка медиа, range-запросы, страницы шаринга и WebDAV могут ехать на одном дизайне хранилища.

• Большое медиа остаётся перематываемым.
• Генераторы превью могут работать с потоками зашифрованных чанков.
• Ответы на HTTP Range не требуют временных копий всего файла.

Модель восстановления

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

• Снимки — полноценные операции над раскладкой.
• Версии и корзина живут в том же жизненном цикле.
• Контент без ссылок перепроверяется перед освобождением.

Операционная модель

Фоновое хеширование манифестов, проверки согласованности хранилища, генерация превью, очистка токенов и очистка временных данных — часть пути продукта. Оператор получает явные предупреждения, а не узнаёт о тихом расхождении в хранилище постфактум.

Доказательство модели хранилища

Страница архитектуры не просит поверить диаграмме. Доказательство продукта видно в словаре и интерфейсе: чанки, манифесты, снимки, версии, range-чтения, WebDAV, превью и проверки целостности — все упираются в одну модель.

• Идентичность чанка по SHA-256 — якорь хранилища.
• Манифесты описывают байты файла отдельно от раскладки папок.
• Снимки и восстановление работают по ссылкам, а не копируют каждый байт заново.

Почему модель продаёт продукт

Cotton лучше всего ложится туда, где хочется файловое облако, чьи внутренности объясняют продукт, а не спорят с ним. Та же архитектура, которая делает большие файлы практичными, делает восстановление, шаринг, превью и очистку проще для понимания.

Когда проще — лучше

Движок хранения, где чанки на первом месте, требует больше дисциплины, чем примонтировать папку и назвать её облаком. Если нужен широкий набор приложений или прямая семантика файловой системы, groupware-стек или обычный файловый сервер могут подойти лучше.