Один GIF-файл из сериала «Друзья» увеличил резервную копию сайта на 377 ГБ, превысив лимит файловой системы

Один популярный GIF-реакция, часто используемый участниками сообщества сайта в чатах, увеличил размер резервной копии на 377 ГБ и даже мог привести к сбою процесса бэкапа. Анимация «счастливого танца» Дженнифер Энистон весит 1,6 МБ, но в конкретном случае, описанном техническим блогером Discourse Джейком Голдсборо, она была продублирована 246 173 раза в резервной копии. Проблема была вызвана, мягко говоря, чрезмерным использованием этого GIF-файла в сочетании с политикой безопасности файлов. Решение оказалось не самым простым.

GIF с Рэйчел из сериала «Друзья», танцующей от счастья, был продублирован 246 173 раза на одном сайте Discourse. 1,6 МБ превратились в 377 ГБ раздутого бэкапа и сломали лимит файловой системы. Оказывается, Дженнифер Энистон может стресс-тестировать инфраструктуру.

Discourse — это компания и проект ПО с открытым исходным кодом, создающий одну из самых популярных современных платформ для обсуждений в сообществах, которая в настоящее время обслуживает более 22 000 онлайн-сообществ. Её платформа для чатов в реальном времени позволяет пользователям вставлять эмодзи и GIF-файлы в обсуждения, чтобы оживить дебаты. Однако функция «безопасных загрузок» платформы означает, что «когда файл перемещается между контекстами безопасности (например, из личного сообщения в публичный пост), система создает новую копию со случайным SHA1», — объясняет Голдсборо. «Исходное содержимое идентично, но Discourse рассматривает его как новый файл». Таким образом, популярное изображение или GIF-реакция распространяются по постам, репостам и личным сообщениям, и каждый контекст создает еще одну копию файла.

Первая попытка Discourse исправить систему, перегруженную дубликатами, заключалась в отслеживании оригинального контента по его хэшу. Затем при резервном копировании загрузки группировались по хэшу, и скачивался только первый файл в каждой группе. Для любых дубликатов создавались жёсткие ссылки (hardlinks).

Никто не говорил им, что жизнь будет такой

Это казалось элегантным решением, пока один из крупных клиентов Discourse не напомнил всем о лимите файловой системы ext4 — примерно 65 000 жёстких ссылок на один inode. В описанном случае резервное копирование с этим первым исправлением работало, но «вместо одной загрузки для всех 246 173 дубликатов мы получили одну загрузку плюс ~181 000 дополнительных загрузок после достижения лимита», — объясняется в блоге компании. «Не та победа, на которую я рассчитывал».

У другого клиента Discourse было 432 ГБ загруженных файлов и соответственно объёмный бэкап. Однако анализ показал, что уникальный контент составлял всего 26 ГБ. Другими словами, дубликаты стали причиной увеличения в 16 раз.

Абсурдно размноженный файл, создавший 377 ГБ «раздутия», был GIF с Рэйчел из «Друзей», исполняющей свой счастливый танец. Таким образом, проблемный сайт был, очевидно, весьма счастливым местом, где эта GIF-реакция «постоянно использовалась в постах, личных сообщениях, везде», — отметили в Discourse.

К счастью, Discourse удалось придумать исправление для своего предыдущего исправления. По сути, новое решение начинается так же, как и старое, — с создания жёстких ссылок. Но когда файловая система выдаёт ошибку EMLINK (слишком много жёстких ссылок), она копирует файл локально и рассматривает новый файл как «основной», пока снова не будет достигнут лимит. Эта новая мера «работает на любой файловой системе, не требуя настройки», — с некоторым удовлетворением заявляют в Discourse.

Discourse завершает статью, выделяя уроки, извлечённые из этой сбивающей с толку анимации с дубликатами, с иронией отмечая, что «теперь я знаю, что Дженнифер Энистон может стресс-тестировать инфраструктуру».

Источник: Tomshardware.com

ИИ: Забавный и поучительный случай, который наглядно показывает, как, казалось бы, незначительная деталь пользовательского опыта (GIF-реакция) может обернуться серьёзной технической проблемой на уровне инфраструктуры. История лишний раз подтверждает, что при проектировании систем важно учитывать не только типичные сценарии, но и «крайние случаи», порождаемые поведением пользователей. В 2026 году, когда объёмы пользовательского контента продолжают расти, подобные оптимизации становятся критически важными.