On 12/22/2013 04:18 AM, Stan Hoeppner wrote: > For the record, again, I've never used dm-crypt. I'm just trying to > work through the layers to identify the source of Kevin's problems. So > please don't clobber me too hard for going OT, or trying to speak > (somewhat) intelligently about something I'm just learning about... This stuff isn't easy. There are a lot of security-vs-speed tradeoffs, and kernel support varies by processor and architecture. Take this example from x86: # info from fdisk: /dev/sda5 8404992 10502143 1048576 83 Linux # cryptsetup status /dev/mapper/wCrypt /dev/mapper/wCrypt is active. type: LUKS1 cipher: aes-xts-essiv:sha256 keysize: 512 bits device: /dev/sda5 offset: 4096 sectors size: 2093056 sectors mode: read/write What this jibberish means from a speed standpoint is this: aes: had assembly speedups in the kernel; NIST approved; xts: almost as fast as cbc while being more secure; essiv: "plain" is faster, but essiv is more secure; sha256: it seemed like an ok hash; 512 bits: much slower than 256 or 128 bits, but hopefully more secure, fine for a small partition like this. A similar "cryptsetup status <cryptname>" from Kevin might help you benchmark things, and Kevin might explain his rationale without blowing his cover ;-) A `zcat /proc/config.gz` | grep CRYPTO` might help you see what kernel support he has as well. Dave's recent post about I/O latency with dm-crypt reads/writes might be the answer that you're seeking. I just wanted to put in my two cents. Good luck! Michael _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
