Baixo desempenho de gravação no ecryptfs

Question

Eu fiz um benchmarking com ecryptfs e dm-crypt e obtive alguns resultados interessantes. Tudo o que se segue foi feito com um sistema de arquivos Btrfs, usando dd para copiar um arquivo ~ 700MB de / para um ramdisk com a opção conv=fdatasync para forçar a sincronização de dados. Caches de disco foram apagados antes de cada teste.

No encryption:
 read - 165MB/s
 write - 120MB/s
ecryptfs:
 read - 125MB/s
 write - 15MB/s
dm-crypt:
 read - 150MB/s
 write - 115MB/s
dm-crypt + ecryptfs:
 read - 120MB/s
 write - 15MB/s

Agora eu entendo que a criptografia é mais lenta que um sistema de arquivos raw, no entanto, eu não esperava a queda massiva de desempenho de gravação com o ecryptfs. O fato de eu estar forçando a sincronização de dados torna esse teste irreal? Ou há alguma opção que eu possa passar para o ecryptfs para que as gravações funcionem mais rápido?

Eu estava usando criptografia de nome de arquivo no ecryptfs, mas além disso, tudo estava definido como padrão.

    

Answer 1

Página man de dd sobre fdatasync lê: physically write output file data before finishing , portanto só grava dados fisicamente "uma vez" (lê-lo como "não forçar um flush a cada X blocos ou bytes, mas um único flush no final "). Se você estiver usando dd para fazer seus testes, é a melhor maneira de obter os resultados mais precisos. Pelo contrário, não usar esse sinalizador específico, tornaria seus resultados irrealistas: omitir provavelmente perderia o tempo para a própria criptografia, pois dd é apenas cópia de dados.

No entanto, também achei que havia algo acontecendo em relação aos seus resultados, mas achei este artigo que mostra quase o mesmo: ecryptfs é dolorosamente lento. E o seu teste ( um único arquivo sendo copiado) é o melhor cenário para o ecryptfs!

Como o ecryptfs grava um arquivo criptografado (com um cabeçalho personalizado com metadados dentro) para cada versão de texto não criptografado, ter muitos arquivos pequenos implica uma queda de desempenho ainda maior.

No entanto, o ecryptfs tem seus benefícios: você pode enviar um arquivo criptografado imediatamente sem perder a criptografia. Seus backups (supondo que você esteja fazendo o backup de seus dados criptografados ) seriam mais rápidos, já que você copiaria arquivos tão grandes quanto os seus dados (e ainda mais rápidos se forem incrementais, pois você copiaria arquivos modificados) .

dm-crypt, por outro lado, pode ser muito mais rápido, mas você precisaria enviar o container inteiro (um sistema de arquivos inteiro) para manter a criptografia como está. E os backups também consistiriam em todo o contêiner, não sendo capazes de fazer backups incrementais na maioria dos casos.

Eu usei (e ainda uso) ambos os métodos (não as mesmas ferramentas, no entanto) para armazenar dados criptografados: é mais fácil manter a sincronização baseada em arquivos (ecryptfs) via serviços de hospedagem online, como dropbox entre PCs, mas é muito lento ao fazer mudanças e causou-me alguns problemas com o sistema de arquivos underlaying (ele assume que pode gravar os arquivos e problemas relacionados a limites no sistema de arquivos tendem a quebrar a coisa toda); Eu prefiro a criptografia de dispositivo de bloco: eu os trato como partições simples, então os limites e as questões não se partem tão mal. A única desvantagem é copiar o contêiner, que pode demorar mais tempo.