GIF‑клипът с танца на Рейчъл от „Приятели“ се разраства до стотици гигабайти и руши резервните копия на Discourse

GIF‑клипът с танца на Рейчъл от „Приятели“ се разраства до стотици гигабайти и руши резервните копия на Discourse

2 hardware

Кратко съдържание

Discourse е популярна платформа за онлайн дискусии, на която сега има над 22 000 общности.

Наскоро при архивиране на сайта възникна критична проблем: един GIF‑файл (1,6 МБ) беше копиран от потребителите 246 173 пъти, което превишава лимита за твърди връзки в файловата система ext4 и доведе до увеличение размера на архивния файл до 377 ГБ.

По-долу е подробен разбор на ситуацията, причините и решенията.

1. Какво се случи?
ЕлементДанниПлатформаDiscourseКоличество общности>22 000Файл‑проблем GIF „Рейчел от „Friends“, размер 1,6 МБЧисло копия 246 173 (твърди връзки)Лимит ext4~65 000 твърди връзки на един inodeКраен размер на архив 377 ГБ
Защо се случи това?
Discourse позволява вмъкване на емоджита и GIF‑файлове във всички съобщения.

При преместване на файл от един контекст в друг (например от личен чат в публична публикация) системата създава нова копия с произволен SHA‑1 хеш. Това означава, че дори ако съдържанието е идентично, Discourse го разглежда като нов обект.

Така един GIF може да се появи в десетки хиляди съобщения и лични чатове – всеки път се генерира отделен файл. В крайна сметка 246 173 копия превишиха лимита ext4, а системата започна да създава нови файлове вместо твърди връзки, което доведе до „потеря“ на 181 000 архивни копия.

2. Първото решение – хеш‑сборка
Discourse първо се опита да реши проблема, групирайки качванията по SHA‑1:

1. При архивиране всички файлове се събираха в групи със същия хеш.
2. Качваше само първата копие от всяка група.
3. За останалите се създавали твърди връзки.

Това изглеждало елегантно – но не взимаше предвид ограничението ext4 за броя на връзките. След като лимитът беше достигнат, системата автоматично създаваше нови файлове вместо връзки и размерът на архива се увеличаваше внезапно.

3. Ново решение – „преминаване“ при грешка EMLINK
Discourse разработи по-гъвкава стратегия:

1. Създава се твърда връзка към файла, както обикновено.
2. Ако файловата система върне грешка EMLINK (превишен лимит на връзки), следващото копие става „основно“ файл.
3. От този момент нататък новите връзки отново се създават към тази нова основна версия.

Така при всяко превишаване на лимита се преминава към нов “родителски” файл, а системата продължава да работи без грешки. Това решение е съвместимо с всяка файловата система и не изисква допълнителни настройки.

4. Итоги и заключения
- Един популярен GIF (танцът на Рейчел от „Friends“) стана причина за увеличението на резервното копиране до 377 ГБ.
- Ограничението ext4 около 65 000 твърди връзки се оказа критичен фактор.
- Първото решение с хеш‑сборка не взеха предвид файловите ограничения, което доведе до загуба на данни.
- Новата стратегия „преминаване“ при грешка EMLINK позволява коректно управление на голям брой копия и запазва ефективността на резервното копиране.

> *„Сега знаем, че Дженисър Енстън може да провежда стрес‑тестове на инфраструктурата“,* — с ирония отбеляза Discourse в своя блог.

Коментари (0)

Споделете мнението си — моля, бъдете учтиви и по темата.

Все още няма коментари. Оставете коментар и споделете мнението си!

За да оставите коментар, моля, влезте в профила си.

Влезте, за да коментирате