Awaria kopii zapasowej z powodu duplikatów GIF w Discourse

# Jak jeden plik GIF spowodował awarię kopii zapasowej w Discourse

Podczas tworzenia kopii zapasowej jednego z forów na platformie Discourse wystąpił niezwykły przypadek: ten sam plik GIF o rozmiarze 1,6 MB został zduplikowany 246 173 razy. W efekcie rozmiar kopii zapasowej zwiększył się o 377 GB, doszło do uszkodzenia systemu plików Linux oraz całkowitego zawieszenia procesu backupu. Problem nie wynikał z błędu w kodzie, lecz z cech architektury bezpieczeństwa platformy i ograniczeń systemu plików ext4.

Dlaczego jeden plik stał się setkami tysięcy kopii

Discourse korzysta z mechanizmu „bezpiecznego wgrywania”, w ramach którego za każdym razem, gdy plik jest przenoszony między różnymi kontekstami (np. z prywatnej wiadomości do publicznego posta), system tworzy nową kopię z unikalnym hashem SHA1. Chociaż zawartość pliku pozostaje identyczna, platforma traktuje go jako oddzielny obiekt. Jest to niezbędne do przestrzegania polityk bezpieczeństwa i zapobiegania nieautoryzowanemu dostępowi do plików multimedialnych.

W przypadku popularnego GIF-a — tańczącej Rachel z serialu „Przyjaciele” — użytkownicy wielokrotnie wstawiali go do różnych wątków, komentarzy i prywatnych rozmów. Każde użycie w nowym kontekście generowało nowy wpis w bazie danych i nowy plik na dysku, mimo identycznej zawartości binarnej.

Pierwsza próba optymalizacji: twarde linki

Zespół Discourse opracował rozwiązanie oparte na grupowaniu plików według hasha zawartości podczas backupu. Dla każdej grupy duplikatów przechowywano tylko jedną fizyczną kopię, a pozostałe zastępowano twardymi linkami (hard links) do niej. Taki sposób znacznie zmniejszał rozmiar kopii zapasowych i działał poprawnie na większości instalacji.

Podczas testów na dużym forum klienta okazało się jednak, że system plików ext4 ma ograniczenie: maksymalnie około 65 000 twardych linków na jeden inode. W sytuacji z 246 173 duplikatami po osiągnięciu limitu system zaczął tworzyć nowe fizyczne kopie — już nie jako duplikaty, ale samodzielne pliki. W rezultacie zamiast jednej kopii powstało ~181 000 dodatkowych plików, co rozwiązało problem tylko częściowo.

Ostateczne rozwiązanie: dynamiczne przełączanie między linkami a kopiami

Nowe rozwiązanie uwzględnia ograniczenia systemu plików i działa uniwersalnie:

• System zaczyna od tworzenia twardych linków, jak poprzednio.
• Po otrzymaniu błędu EMLINK („Zbyt wiele linków”) od jądra Linux proces przełącza się na lokalne kopiowanie pliku.
• Nowa kopia staje się „główną” dla kolejnych linków, a cykl powtarza się po osiągnięciu nowego limitu.

Ten sposób nie wymaga konfiguracji systemu plików, jest zgodny z każdą POSIX-kompatybilną OWith i efektywnie zmniejsza rozmiar kopii zapasowych nawet przy ekstremalnej liczbie duplikatów.

Przykład logiki przetwarzania (uproszczony):

if hard_link_fails_with_emlink?
  create_new_physical_copy
  reset_link_counter
end

Co ważne

• Bezpieczeństwo vs. efektywność: Architektoniczne decyzje nastawione na izolację kontekstów mogą powodować nieoczekiwane skutki uboczne przy skalowaniu.
• Ograniczenia systemów plików są realne: Nawet takie „niskopoziomowe” limity jak 65K hard links na inode w ext4 mogą zakłócić działanie wysokopoziomowych aplikacji.
• Uniwersalne rozwiązania są lepsze: Adaptacyjny algorytm reagujący na błędy OWith działa pewniej niż statyczna optymalizacja pod idealne warunki.
• Popularna zawartość to źródło obciążenia: Często używane pliki multimedialne (emotikony, reakcje, memy) stają się ukrytymi motorami zużycia zasobów.
• Testy na danych produkcyjnych są kluczowe: Tylko rzeczywiste scenariusze użycia ujawniają takie edge cases.

Lekcje dla twórców rozproszonych systemów

Przypadek Discourse ilustruje klasyczną dylemat: jak równoważyć bezpieczeństwo danych z efektywnością przechowywania. Przy projektowaniu systemów obsługujących treści użytkownika warto uwzględnić:

• Możliwość deduplikacji na poziomie aplikacji przed zapisem na dysk.
• Konieczność monitorowania metryk związanych z liczbą plików i ich duplikatami.
• Wagę graceful degradation przy zderzeniu z ograniczeniami systemowymi.

Chociaż problem wywołało masowe użycie jednego GIF-a, jego korzenie tkwią w architektonicznych kompromisach. Rozwiązanie znalezione przez zespół Discourse może służyć za przykład dla innych projektów stojących przed podobnymi wyzwaniami.

— Editorial Team