Hi, On 12/27/2010 06:03 PM, Robert.Heinzmann@xxxxxxxxxxxxxxx wrote: > I do this for plain ext3 filesystem on /dev/sdf and ext3 on crypto > filesystem (I use dm_crypt and truecrypt as backends). Please note that truecrypt uses dmcrypt in recent versions (and if kernel support requested mode). (Note that CentOS 5 kernel cannot do XTS mode, one day it will be backported though.) > I also see that the disk writes are split in 4k: > Because this is cached I/O (buffer cache), dm_requests are processed > in units of 4k (somehow this seems to be a implementation specific > thing). dmcrypt doesn't limit io operation if directly submitted to it, but stacking of devices can limit it. No idea about that ext3 thing though. Because in RHEL5 kernel is not yet implemented merge callback in DM targets, all stacked targets must split io operation to 4k (page) units. (This is fixed long time ago upstream.) > Then this small requests are merged again in the scheduler for > the /dev/sdf backend device. I would expect that this is not such a > big issue. exactly > It also looks like dm_crypt does only scale to one CPU Core per device. Yes, this is known limitation. I know about some problems, some of them are partially fixed in devel tree (and targeted to 2.6.38) some will be based on top of these changes (latency problem is one of them probably). I do not want to speculate what exactly causes latency issues - it is not one thing (testing of per-cpu worker threads changes shows that page cache and fs are also important part which can contribute to some problems here etc.) But all these change will be upstream - old kernels, like RHEL5 are maintained with focus to stability (most of changes are not backportable anyway). If you are Red Hat customer, you can of course request this through support. Milan _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
