A pré-busca e / ou buffer de dados do eCryptfs?

Question

Eu tenho experimentado usar o eCryptfs como o sistema de arquivos subjacente para dados MySQL para imitar a criptografia de dados transparente para o MySQL. Fiz alguns testes para medir a sobrecarga de decriptografia quando o MySQL lê dados e estou obtendo resultados estranhos.

Eu preparei uma tabela com tamanho de 7,5 GB e executei uma consulta de varredura completa da tabela (SUM). Eu tenho dois cenários -

1. Quando o fs subjacente é ext4 e não há criptografia, o tempo médio da consulta em várias execuções - 22,5 segundos
2. eCryptfs montado no topo do ext4 -
   • Quando a tabela é criada pela primeira vez, o tempo de execução médio da consulta é de 21 segundos (como é menor do que a não criptografada, há alguma pré-busca envolvida?)
   • Limpe os buffers do MySQL e execute novamente a consulta, o tempo médio de execução agora é 9.6 segundos (devido ao buffer do eCryptfs?)
   • Se eu desmontar meu diretório e remontá-lo, mas não recriar os dados, o tempo médio será de cerca de 17 segundos . Isso é novamente misterioso. O eCryptfs armazenou algumas meta informações não criptografadas quando foi descriptografado pela primeira vez?

Eu executei esses testes várias vezes (limpando os buffers do MySQL toda vez) e obtive resultados consistentes. Alguém pode me explicar ou me indicar um recurso que explique esse comportamento? É possível desabilitar isso (para os testes)?

    

Answer 1

Eu fiz a mesma pergunta na lista de discussão do eCryptfs. Este é o tópico -

link

Um dos principais colaboradores, Tyler Hicks respondeu à consulta, copiada aqui (no caso de o link ficar inativo)

== BeginMessage ==

Os seus resultados de teste não fazem sentido para mim à primeira vista.

Na maioria das versões do kernel, o eCryptfs usa o cache de gravação. Houve algumas versões do kernel em que um cache de write-back era implementado, mas causou alguns problemas e esse patch foi revertido.

Para a consulta SUM que você está fazendo, esperaria que fosse todas as leituras, write-back ou write-through não importa muito. Haveria um camada de cache das páginas criptografadas no sistema de arquivos inferior e, em seguida, outra camada em cache das páginas descriptografadas no nível eCryptfs, por isso é certamente diferente de quando você está apenas usando o ext4 simples.

Você falou sobre limpar os buffers do MySQL e o cache da página do eCryptfs (desmontando e remontando eCryptfs) entre testes. Ainda há o cache da página do sistema de arquivos inferior que não está sendo limpo. Talvez aquilo tem algo a ver com isso, mas duvido que seja a história completa aqui.

Você está usando innodb_flush_method = O_DIRECT? O eCryptfs não implementa E / S direta, então não tenho certeza de como o MySQL lidaria com isso no topo eCryptfs vs. ext4, que faz diretamente I / O.

Isso é algo que eu teria que aprofundar para fazer qualquer sentido de isto. O que você está vendo é definitivamente estranho.

== Fim da mensagem ==