Detalhes técnicos do recurso de deduplicação do Server 2012

Agora que o Windows Server 2012 vem com recursos de deduplicação para volumes NTFS , estou com dificuldade para encontrar detalhes técnicos sobre ele. Posso deduzir da documentação do TechNet que a própria ação de deduplicação é um processo assíncrono - não muito diferente de como o SIS Groveler costumava trabalhar - mas praticamente não há detalhes sobre a implementação (algoritmos utilizados, recursos necessários e até informações sobre desempenho) considerações nada mais são do que recomendações em estilo de regra de ouro).

Informações e sugestões são muito apreciadas, uma comparação com a eficiência de desduplicação do ZFS do Solaris para um conjunto de cenários seria maravilhosa.

Como eu suspeitava, é baseado no subsistema VSS ( origem ), o que também explica sua natureza assíncrona. Os de-dupe chunks são armazenados em \System Volume Information\Dedup\ChunkStore\*, com as configurações em \System Volume Information\Dedup\Settings\*. Isso tem impactos significativos na maneira como o software de backup interage com esses volumes, o que é explicado no artigo vinculado (em resumo: sem o suporte à desduplicação, seus backups terão o mesmo tamanho de sempre, com o suporte à desduplicação, você apenas fará o backup a loja de desduplicação muito menor).

Quanto aos métodos utilizados, o melhor que pude encontrar foi um trabalho de pesquisa publicado por um pesquisador da Microsoft em 2011 ( fonte , texto completo ) na conferência Usenix FAST11. A seção 3.3 entra em Desduplicação no armazenamento primário . Parece provável que esses dados tenham sido usados ​​no desenvolvimento do recurso de desduplicação do NTFS. Esta citação foi usada:

O algoritmo canônico para blocos definidos por conteúdo de tamanho variável é Rabin Fingerprints [25].

Há muitos dados no artigo para analisar, mas a complexidade do conjunto de ferramentas que eles usaram, combinada com os recursos que já conhecemos em 2012, sugerem fortemente que o raciocínio do artigo foi usado para desenvolver os recursos. Não podemos ter certeza sem os artigos do msdn, mas isso é o mais próximo que podemos chegar por enquanto.

As comparações de desempenho com o ZFS terão que esperar até que os comparadores o concluam.