Chyba zálohování kvůli duplikátům GIF v Discourse

# Jak jeden GIF soubor způsobil selhání zálohování v Discourse

Při zálohování jednoho z fór na platformě Discourse došlo k anomálnímu případu: stejný GIF soubor o velikosti 1,6 MB byl duplikován 246 173krát. To vedlo k nárůstu objemu zálohy o 377 GB, poškození souborového systému Linux a úplnému selhání procesu zálohování. Problém nevznikl kvůli chybě v kódu, ale kvůli specifikům bezpečnostní architektury platformy a omezením souborového systému ext4.

Proč se z jednoho souboru staly stovky tisíc kopií

Discourse používá mechanismus „bezpečné nahrávání", při kterém se pokaždé, když se soubor přesouvá mezi různými kontexty (např. z soukromé zprávy do veřejného příspěvku), vytvoří nová kopie s unikátním SHA1 hašem. Ačkoli obsah souboru zůstává identický, platforma ho bere jako samostatný objekt. To je nutné pro dodržení bezpečnostních politik a prevenci neoprávněného přístupu k mediálním souborům.

V případě populárního GIF souboru – tančící Rachel z seriálu Přátelé – uživatelé ho opakovaně vkládali do různých témat, komentářů a soukromých konverzací. Každé použití v novém kontextu vytvářelo nový záznam v databázi a nový soubor na disku, navzdory úplné shodě binárního obsahu.

První pokus o optimalizaci: pevné odkazy

Tým Discourse vyvinul řešení založené na seskupování souborů podle haše obsahu během zálohování. Pro každou skupinu duplikátů se uchovávala pouze jedna fyzická kopie a zbývající byly nahrazeny pevnými odkazy (hard links) na ni. Tento přístup výrazně snižoval objem záloh a fungoval správně na většině instancí.

Při testování na velkém klientském fóru se však ukázalo, že souborový systém ext4 má omezení: maximum přibližně 65 000 pevných odkazů na jeden inode. V případě 246 173 duplikátů to znamenalo, že po vyčerpání limitu systém začal vytvářet nové fyzické kopie – ne jako duplikáty, ale jako samostatné soubory. Výsledkem bylo místo jedné kopie přibližně 181 000 dalších souborů, což problém pouze částečně vyřešilo.

Finální řešení: dynamické přepínání mezi odkazy a kopiemi

Nové řešení zohledňuje omezení souborového systému a funguje univerzálně:

• Systém začíná vytvářením pevných odkazů, stejně jako dříve.
• Při obdržení chyby EMLINK („Příliš mnoho odkazů") od jádra Linux se proces přepne na lokální kopírování souboru.
• Nová kopie se stane „hlavní" pro následující odkazy a cyklus se opakuje při dosažení nového limitu.

Tento přístup nevyžaduje nastavení souborového systému, je kompatibilní s jakoukoli POSIX-kompatibilní OS a efektivně snižuje objem záloh i při extrémním počtu duplikátů.

Příklad logiky zpracování (zjednodušeně):

if hard_link_fails_with_emlink?
  create_new_physical_copy
  reset_link_counter
end

Co je důležité

• Bezpečnost vs. efektivita: Architektonická řešení zaměřená na izolaci kontextů mohou při škálování způsobit nečekané vedlejší efekty.
• Omezení souborových systémů jsou reálná: Dokonce i takové „nízkourovňové" limity, jako 65K pevných odkazů na inode v ext4, dokážou narušit fungování vysokoúrovňových aplikací.
• Univerzální řešení jsou lepší: Adaptivní algoritmus reagující na chyby OS funguje spolehlivěji než statická optimalizace pro ideální podmínky.
• Populární obsah je zdrojem zátěže: Často používané mediální soubory (emotikony, reakce, memy) se stávají skrytými řidiči spotřeby zdrojů.
• Testování na produkčních datech je klíčové: Pouze reálné scénáře použití odhalí takové okrajové případy.

Lekce pro vývojáře distribuovaných systémů

Případ Discourse demonstruje klasickou dilematu: jak vyvažovat mezi bezpečností dat a efektivitou úložiště. Při návrhu systémů pracujících s uživatelským obsahem by mělo být zohledněno:

• Možnost deduplikace na úrovni aplikace před zápisem na disk.
• Nutnost monitorování metrik souvisejících s počtem souborů a jejich duplikátů.
• Důležitost plynulého útlumu při kolizi se systémovými limity.

Ačkoli problém vznikl kvůli masovému použití jednoho GIF, jeho kořeny jsou v architektonických kompromisech. Řešení, které tým Discourse našel, může sloužit jako příklad pro jiné projekty čelící podobným výzvám.

— Editorial Team