Baixo desempenho de gravação no ecryptfs

Fiz alguns testes comparativos com ecryptfs e dm-crypt, e obtive alguns resultados interessantes. Todos os itens a seguir foram feitos com um sistema de arquivos Btrfs, usando ddpara copiar um arquivo de ~ 700 MB para / de um ramdisk com a conv=fdatasyncopção de forçar a sincronização de dados. Os caches de disco foram limpos 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 bruto, no entanto, eu não esperava a queda maciça do desempenho de gravação com o ecryptfs. O fato de eu estar forçando a sincronização de dados torna esse teste irrealista? Ou existem opções que eu possa passar para o ecryptfs para que as gravações funcionem mais rapidamente?

Eu estava usando criptografia de nome de arquivo no ecryptfs, mas fora isso tudo estava definido como padrão.

— Xenopático
fonte

O benchmarking pode ser difícil e, às vezes, o teste atinge alguns limites inesperados, especialmente ao forçar gravações síncronas. Não estou familiarizado com o funcionamento interno do ecryptfs, mas certifique-se de descartar quaisquer problemas de amplificação de gravação. Qual o tamanho do bloco usado pelo ecryptfs e o que você especificou para o dd? Se o ecryptfs criptografar 16kb de cada vez e você estiver gravando blocos menores, cada sincronização forçará uma leitura a buscar o bloco, altere os dados, criptografe e, finalmente, escreva. Isso poderia explicar números de desempenho como estes.

— Ketil

A página de manual de ddabout fdatasynclê:, physically write output file data before finishingportanto, ele grava dados fisicamente "apenas uma vez" (leia-os como "não forçando uma descarga a cada X bloco ou bytes, mas uma descarga única no final"). Se você estiver usando ddpara fazer seus testes, é a melhor maneira de obter resultados mais precisos. Pelo contrário, não usar esse sinalizador específico, tornaria seus resultados irreais: omitir isso provavelmente perderia o tempo para a criptografia em si, pois ddestá apenas copiando os dados.

No entanto, também pensei que havia algo acontecendo nos seus resultados, mas achei este artigo que mostra quase a mesma coisa: ecryptfs é dolorosamente lento. E seu teste ( um único arquivo sendo copiado) é o melhor cenário para ecryptfs!

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

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 backup de seus dados criptografados ) seriam mais rápidos, pois você copiaria apenas arquivos tão grandes quanto os dados (e ainda mais rápido se eles forem incrementais, pois você apenas copiaria arquivos modificados).

O dm-crypt, por outro lado, pode ser muito mais rápido, mas você precisaria enviar o contêiner 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 possível fazer backups incrementais na maioria dos casos.

Eu usei (e ainda uso) os dois métodos (mas não as mesmas ferramentas) para armazenar dados criptografados: com base em arquivo (ecryptfs) é mais fácil manter a sincronização por meio de serviços de hospedagem on-line, como dropbox entre PCs, mas é bem lento quando fazer alterações e me causou alguns problemas no sistema de arquivos subjacente (pressupõe que ele possa gravar os arquivos e problemas relacionados aos limites no sistema de arquivos tendem a quebrar tudo); Prefiro a criptografia do dispositivo de bloco: trato-as como partições simples, para que os limites e problemas não sejam tão prejudiciais. A única desvantagem é copiar o contêiner, que pode demorar muito mais.

— NuTTyX
fonte