XFS blocked task in xlog_cil_force_lsn

[Michael L. Semon]

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