Para tornar o apagamento viável para dados quentes, é necessário pensar em uma codificação de eliminação que funcione bem em um tamanho de bloco de dados que corresponda ao usado pelo sistema de arquivos (geralmente 4K). No entanto, isso não é suficiente, também temos que pensar sobre a arquitetura do seu sistema de arquivos e, em particular, sobre o possível impacto nos metadados (normalmente onde estão os servidores onde cada bloco foi armazenado, etc ...).
Portanto, para construir um sistema de arquivos que usa código de apagamento, precisamos pensar em construir o sistema de arquivos em torno do código de apagamento, em vez de apenas adicionar a codificação de apagamento. em um sistema de arquivos existente.
Uma desvantagem comum sobre a codificação de eliminação era sobre o tempo de CPU e a maior parte da implementação baseada em Reed-Solomon fazia isso em tamanho de bloco grande para compensar o problema de taxa de transferência. Por esse motivo, a maioria deles é voltada apenas para arquivamento.
No entanto, existem algumas alternativas para fazê-lo funcionar em pequenos blocos de dados (4K). Em nosso produto NAS scale-out (RozoFS) usamos outro algoritmo de codificação de apagamento (geométrico versus algébrico para o caso do Reed solomon) que tem a vantagem de fornecer codificação / decodificação rápida em tamanho pequeno de bloco de dados (mais de 10 GBytes / s em um intel I7 @ 2GHz).
A velocidade de codificação / decodificação associada ao fato de que ela opera no tamanho do bloco no intervalo do sistema de arquivos permite evitar a penalidade em leituras extras em solicitações aleatórias de gravação. E, a propósito, podemos abordar o caso dos dados ativos e, em particular, o caso da E / S aleatória em tamanho de bloco de dados pequeno.
Na sua interessante sobre os detalhes em termos de desempenho, temos um site onde postamos o benchmark que fizemos Iozone (testes de acesso seqüencial e aleatório). (rozofs.com - seção do blog)).