Vlákno názorů k článku
Dropbox kvůli chybě ukazoval několik let smazané soubory od Sadam - No myslim si ze by si za ty...

No myslim si ze by si za ty roky a vsimli ze jim nesedi pocet souboru s poctem souboru v DB a nebo ze jim nesedi SUM(size) se zabranym mistem na discich... takze jestli tam byla metadata, tak se tam pravdepodobne nekde valela i data

A co třeba deduplikace? Hádal bych, že Dropbox nefunguje tak jednoduše, jako když si nakopírujete data na flash disk (čímž samozřejmě nevylučuju možnost deduplikace na flashce :) ).

Deduplikace potrebuje vela RAM, vid napr ako to robi zfs, takze nie je to take jednoduche ako to vyzera....

RAM potrebujes jen pokud to nechces davat na disk (a chces to delat online a rychle) a pokud se bavime o nejakym pidisystemu. Deduplikaci muzes klidne delat treba tak, ze pri zapisu spocitas hash bloku dat a ten posles na uplne jiny zelezo do nejaky databaze, a kdyz se ti vrati ze nasel, tak misto zapisu jen nalinkujes prislusnej existujici blok. Samo prevazne to nejdriv nekam zapises a expost to presunujes na deduplikovany uloziste.

Právě jsi vymyslel geniální systém, jak přijít o data. Hint: hash collision

Zase tak moc ne, u ZFS cca 20 GiB pro online dedup stačí. Což je pro server v pohodě. Horší je to s výrazně kolísavým výkonem, každý hash hit totiž znamená read+compare, což u množství dat, která má DropBox, bude poměrně často. Když jsem dělal na projektu, kde se tohle řešilo pro big data, tak se používal online tagging (označení a zařazení podle hashe jako potenciálně dedup; to vyžaduje to množství RAM) + jednou za čas offline dedup (kde díky tomu, že se porovnává hodně bloků se stejným hashem najednou, to dost zrychlí disková cache).