Scarse prestazioni di scrittura su ecryptfs


15

Ho fatto un po 'di benchmarking con ecryptfs e dm-crypt e ho ottenuto alcuni risultati interessanti. Tutto ciò che segue è stato fatto con un filesystem Btrfs, usando ddper copiare un file ~ 700MB su / da un ramdisk con l' conv=fdatasyncopzione per forzare la sincronizzazione dei dati. Le cache del disco sono state cancellate prima di ogni test.

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

Ora capisco che la crittografia è più lenta di un file system non elaborato, tuttavia non mi aspettavo un notevole calo delle prestazioni di scrittura con ecryptfs. Il fatto che sto forzando la sincronizzazione dei dati rende questo test irrealistico? O ci sono opzioni che posso passare a ecryptfs per far funzionare le scritture più velocemente?

Stavo usando la crittografia dei nomi dei file su ecryptfs, ma a parte questo tutto era impostato sui valori predefiniti.


Il benchmarking può essere difficile, e talvolta il test raggiunge alcuni limiti imprevisti, specialmente quando si forzano le scritture sincrone. Non ho familiarità con il funzionamento interno di ecryptfs, ma dovresti assicurarti di escludere eventuali problemi di amplificazione della scrittura. Quale dimensione di blocco utilizza ecryptfs e cosa hai specificato per dd? Se ecryptfs crittografa 16kb alla volta e stai scrivendo blocchi più piccoli, ogni sincronizzazione forzerà una lettura per recuperare il blocco, quindi altererà i dati, quindi crittograferà e infine scriverà. Ciò potrebbe spiegare numeri di prestazioni come questi.
ketil,

Risposte:


2

Man page di ddabout read fdatasync:, physically write output file data before finishingquindi scrive fisicamente i dati solo "una volta" (leggili come "non forzando un flush ogni X blocchi o byte, ma un singolo flush alla fine"). Se si utilizza ddper eseguire i test, è il modo migliore per ottenere risultati più accurati. Al contrario, non usare quel flag specifico, renderebbe i tuoi risultati irrealistici: ometterlo probabilmente perderebbe il tempo per la crittografia stessa poiché ddsta solo copiando i dati.

Tuttavia, ho anche pensato che stesse succedendo qualcosa per quanto riguarda i tuoi risultati, ma ho trovato questo articolo che mostra quasi lo stesso: ecryptfs è dolorosamente lento. E il tuo test ( un singolo file che viene copiato) è lo scenario migliore per ecryptfs!

Poiché ecryptfs scrive un file crittografato (con un'intestazione personalizzata con metadati all'interno) per ogni versione in chiaro, avere molti piccoli file implica anche un calo delle prestazioni ancora maggiore.

Tuttavia, ecryptfs ha i suoi vantaggi: è possibile inviare subito un file crittografato senza perdere la crittografia. I tuoi backup (supponendo che tu stia eseguendo il backup dei dati crittografati ) sarebbero più veloci poiché copieresti solo file grandi quanto i tuoi dati (e anche più veloci se sono incrementali, in quanto copieresti solo i file modificati).

dm-crypt, d'altra parte, potrebbe essere molto più veloce ma sarebbe necessario inviare l'intero contenitore (un intero file system) per mantenere la crittografia così com'è. E i backup consisterebbero anche nell'intero contenitore, non potendo eseguire backup incrementali nella maggior parte dei casi.

Ho usato (e continuo a usare) entrambi i metodi (non gli stessi strumenti, però) per conservare i dati crittografati: basato su file (ecryptfs) è più facile da sincronizzare tramite servizi di hosting online come dropbox tra PC, ma è piuttosto lento quando apportare modifiche e mi ha causato alcuni problemi con il filesystem sottostante (presuppone che sia in grado di scrivere i file e che i problemi relativi ai limiti sul filesystem tendano a rompere il tutto); Preferisco la crittografia del dispositivo a blocchi: li tratto come semplici partizioni, quindi i limiti e i problemi non si rompono così male. L'unico inconveniente è la copia del contenitore, che può richiedere molto più tempo.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.