Klip GIF z tańcem Rachel z „Przyjaciół” rozrosła się do setek gigabajtów, niszcząc kopie zapasowe Discourse

Krótka treść

Discourse – popularna platforma do dyskusji online, na której obecnie jest ponad 22 000 społeczności.

Niedawno podczas tworzenia kopii zapasowej strony pojawił się krytyczny problem: jeden plik GIF (1,6 MB) został skopiowany przez użytkowników 246 173 razy, co przekroczyło limit liczby dowiązań twardych w systemie plików ext4 i spowodowało wzrost rozmiaru kopii zapasowej do 377 GB.

Poniżej szczegółowy opis sytuacji, przyczyn i rozwiązań.

1. Co się stało?
Element Dane Platforma Discourse Liczba społeczności>22 000 Plik‑problem GIF „Rachel z „Friends“”, rozmiar 1,6 MB Liczba kopii 246 173 (dowiązania twarde) Limit ext4~65 000 dowiązań twardych na jeden inode Końcowy rozmiar kopii zapasowej 377 GB
Dlaczego tak się stało?
Discourse pozwala wstawiać emotikony i pliki GIF do dowolnych wiadomości.

Podczas przenoszenia pliku z jednego kontekstu do innego (np. z prywatnej rozmowy do publicznego posta) system tworzy nową kopię z losowym hashem SHA‑1. Oznacza to, że nawet jeśli zawartość jest identyczna, Discourse traktuje ją jako nowy obiekt.

W ten sposób jeden GIF może pojawić się w dziesiątkach tysięcy wiadomości i prywatnych czatach – każdorazowo generowany jest osobny plik. W rezultacie 246 173 kopii przekroczyły limit ext4, a system zaczął tworzyć nowe pliki zamiast dowiązań twardych, co spowodowało „utracenie” 181 000 kopii zapasowych.

2. Pierwsze rozwiązanie – zbieranie haseł
Discourse najpierw próbował rozwiązać problem, grupując przesyłki według SHA‑1:

1. Podczas tworzenia kopii zapasowej wszystkie pliki były grupowane w grupy o tym samym haśle.

2. Ładowano tylko pierwszą kopię z każdej grupy.

3. Dla pozostałych tworzono dowiązania twarde.

Wyglądało to elegancko – ale nie uwzględniało ograniczenia ext4 na liczbę dowiązań. Gdy limit został osiągnięty, system automatycznie tworzył nowe pliki zamiast dowiązań, a rozmiar kopii zapasowej gwałtownie wzrósł.

3. Nowe rozwiązanie – „przełączanie” przy błędzie EMLINK
Discourse opracował bardziej elastyczną strategię:

1. Tworzy się dowiązanie twarde do pliku, jak zwykle.

2. Jeśli system plików zwraca błąd EMLINK (limit dowiązań przekroczony), kolejna kopia staje się „głównym” plikiem.

3. Od tego momentu nowe dowiązania ponownie tworzone są do tej nowej głównej wersji.

W ten sposób przy każdym przekroczeniu limitu następuje przełączanie na nowy „rodzicowy” plik, a system nadal działa bez błędów. To rozwiązanie jest zgodne z dowolnym systemem plików i nie wymaga dodatkowej konfiguracji.

4. Wnioski i podsumowanie
- Jeden popularny GIF (taniec Rachel z „Friends”) spowodował wzrost kopii zapasowych do 377 GB.

- Ograniczenie ext4 na ~65 000 dowiązań twardych okazało się krytycznym czynnikiem.

- Pierwsze rozwiązanie ze zbieraniem haseł nie uwzględniło ograniczeń systemu plików, co doprowadziło do utraty danych.

- Nowa strategia „przełączania” przy błędzie EMLINK pozwala prawidłowo zarządzać dużą liczbą kopii i zachować wydajność tworzenia kopii zapasowych.

> *„Teraz wiemy, że Jennifer Aniston potrafi przeprowadzić testy obciążeniowe infrastruktury,”* — z ironią zauważył Discourse w swoim blogu.