ecryptfs e muitos arquivos pequenos - desempenho ruim?

Eu tenho uma pasta com algumas centenas de milhares de arquivos pequenos, totalizando cerca de 14 GB de dados. Esta é uma pasta no meu diretório pessoal criptografado ecryptfs.

Fazer uma "pasta dush" leva mais de 9 minutos. Fazer um cp -ral para um local não criptografado leva uma hora e 15 minutos. A carga da CPU durante este tempo é principalmente ligada a IO (80% wa no topo)

Fazer uma "du -sh encryptedfolder" leva apenas 15 segundos e um cp -ral para o mesmo local leva apenas 80 segundos. 'encryptedfolder' é a pasta em /home/.ecryptfs/myname/.Private que contém os arquivos criptografados.

Estou perplexo com o impacto desse desempenho. Esta pasta é backups noturnos via rsync, que agora leva mais de duas horas. Antes de mudar para o ecryptfs, usei o truecrypt e o backup foi executado em 12 minutos.

Por que os ecryptfs são tão lentos neste cenário? As operações du -sh e cp -ral não envolvem qualquer descriptografia do conteúdo do arquivo, apenas localizando o nome do arquivo correto. Existe alguma maneira de acelerar isso?

P.S .: Isso é executado no Ubuntu 11.04

ecryptfs Guy
fonte

Respostas:

Há alguns fatores que contribuem aqui.

Obter uma lista de todos os nomes de arquivos em um diretório requer a decodificação, análise e descriptografia dos nomes de arquivos inferiores.
As chamadas stat () de du causa uma pesquisa, que requer a alocação de um inode eCryptfs, lendo parte dos metadados de arquivo inferiores, verificando se é um arquivo eCryptfs e analisando o tamanho de arquivo não criptografado para definir o campo i_size do inode eCryptfs . Tenha em mente que a leitura dos metadados do sistema de arquivos inferior envolve a leitura de uma página no cache de páginas do sistema de arquivos inferior.

Por causa do design do eCryptfs, ele tem alguma sobrecarga infeliz ao lidar com um grande número de arquivos. Tenho certeza de que há algumas melhorias / aprimoramentos a serem feitos, apesar do design, mas otimizar essa parte do código não tem sido um foco meu anteriormente.

tyhicks
fonte

Ok, isso é um pouco decepcionante. Mas vou apenas mover a pasta para fora do meu diretório pessoal e para um disco seguro TrueCrypt.

Guy

A resposta simples é que não é. O impacto no desempenho não está no fato de o encryptfs ser lento, mas na necessidade de alocar um grande número de inodes e executar a manutenção do disco para colocar todos os metadados associados aos arquivos no disco um por um.

Se a pasta for salva durante a noite, você pode achar mais útil primeiro "tar" todo o diretório, compactar o arquivo resultante e criptografá-lo (não criptografar e compactar, pois a compactação não funciona em arquivos criptografados). Dessa forma, você terá um backup que será consideravelmente menor e muito mais rápido para ser criado e movimentado.

SecurityMatt
fonte

(1) Para du -sh não há necessidade de colocar nada no disco, isso é puramente leitura. (2) Sua sugestão com tar não é mais rápida, porque ainda teria que passar por ecryptfs (como é onde a pasta está armazenada), também prefiro fazer backups incrementais e não obter um novo arquivo enorme todos os dias.

Guy

As leituras ainda precisam passar pela estrutura do inode (que é muito indireta, cada uma exigindo acesso ao disco e uma redefinição dos vetores de criptografia). Seu ponto sobre o tar é válido, mas se você quiser backups incrementais, provavelmente deveria estar usando SVN ou GIT em vez de fazer uma cópia local

SecurityMatt

Obrigado pelo esclarecimento. No entanto, não aceito a premissa de que o svn / git seria um substituto para backups. Sempre. Neste caso, eu nem tenho certeza de que funcionaria ou de tornar as coisas significativamente mais rápidas (ainda precisaria passar por todos os arquivos para ver o que mudou).

Guy

Para justificar meu ponto: blog.codekills.net/2009/12/08/… / ewout.name/2011/10/do-not-store-database-backups-in-git

Guy

Esta é a primeira vez que você mencionou bancos de dados. Você está certo de que você não deve fazer backup de um banco de dados no GIT, mas para arquivos normais que mudam com pouca freqüência (como código-fonte) ainda é uma boa escolha. Para backups de bancos de dados, você provavelmente seria melhor usar diffs incrementais do banco de dados, compactar (e talvez criptografar) o resultado e armazená-los fora do site. Lembre-se de que um backup no local não é um backup quando o site é totalmente gravado.

SecurityMatt