[dm-crypt] Re : Re : Re : Poor performances with nfs and Kernel 3.x

Mickael mki2268 at yahoo.com
Sun Feb 26 22:29:31 CET 2012



> ----- Mail original -----
> De : Arno Wagner <arno at wagner.name>
>  À : dm-crypt at saout.de
>  Cc : 
>  Envoyé le : Jeudi 9 février 2012 8h37
>  Objet : Re: [dm-crypt] Re : Re : Poor performances with nfs and Kernel 3.x
> 
> On Wed, Feb 08, 2012 at 05:55:21PM +0000, Mickael wrote:
> > Here are more tests focusing the CPU load with htop snapshot:
> > 
> > with Kernel 3.x, nfsd threads are using more CPU !?
> 
> This is what I suspected. You setup is already slightly 
> CPU-limited when reading/writing encrypted partitions. 
> Any additional CPU needed by NFS is then directly deduced 
> from CPU available for encryption.
> 
> I have to say this is a pretty special case as reading/writing
> must be CPU limited, but only just about. 
> 
> I have no idea why NFSD needs more CPU though. Maybe add that
> as finding to your LKML post. Maybe also try to contact 
> the NFS folks directly or via bugzilla.kernel.org by
> filing a bug against NFSD in 3.x.
> 
> Possible fixes:
> 1) live with it
> 2) stay with kernel 2.6.x
> 3) use a faster cipher (although AES is pretty optimal here)
> 4) get a faster CPU, or one with at least 2 cores if this is 
>    a single core.
> 
> Arno
> 


Sorry for the late answer.
I've finally compiled the last stable Kernel 3.2.7 this afternoon, and the problem is still here :(

There is an identical bug report on ubuntu launchpad ( https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/879334 ), but I'm not sure if Ubuntu is working on it. (Problem reported when Ubuntu started using 3.0 Kernel in october 2011)
I need to take a look at the NFS mailing list to see if the problem has been reported. The solution is certainly here.

For the moment, I stay with the 2.6 Kernel !

Thanks for your help !
Mickael


PS: about point 3: Have you ever thinking adding an option to cryptsetup to do a benchmark like this: http://www.truecrypt.org/screenshots2 (I guess everyone build his own one)
In fact, with the speed, it will be great to have an idea about the security level of  each cipher too. But is it possible to calculate such index ?
For example, is the slowest cipher the most secure ?


More information about the dm-crypt mailing list