[Top] [All Lists]

Re: XFS blocked task in xlog_cil_force_lsn

To: xfs@xxxxxxxxxxx
Subject: Re: XFS blocked task in xlog_cil_force_lsn
From: "Michael L. Semon" <mlsemon35@xxxxxxxxx>
Date: Sun, 22 Dec 2013 16:01:14 -0500
Delivered-to: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=LEfga3NnGzCs9xt/YCaJ9o0X0h7BJ7WnXncVapE+JpU=; b=Zf2QXalomgm/HijOAJa81m5n/usvp5aAP4FLkNIzNs+kyA8v2fZ7fvB83aU1zU3QPr bEyvb0kz1xqDkX8g9s46w8rusVl42zUE1LGUzWoslBWqgqutyj0R95UIYO1MNeze/8WA P9bPUd7vNcVWXt1jMLqhY8pqWwI8s/O4g3+3h3uZdqNLHSS6CmVluVNQUM545D2JjtxN 9xZ0V18BZjyf9Z53M1omzTvZkBgN0RvzS1fnJmndGp2bhk9YR5pppzXp4OEKmovkeDHy cie4O7asXAeAq5+O7MhZ3mDcZKF0DP5EbKxIP9PtHO3m5GIoOQh4IiSUp6nN+hCSkPrf F6NQ==
In-reply-to: <52B6AE4D.5020104@xxxxxxxxxxxxxxxxx>
References: <52B102FF.8040404@xxxxxxxxxxx> <52B118A9.8080905@xxxxxxxxxxxxxxxxx> <52B178AA.6040302@xxxxxxxxxxx> <52B2FE9E.50307@xxxxxxxxxxxxxxxxx> <52B41B67.9030308@xxxxxxxxxxx> <52B439D1.3020205@xxxxxxxxxxxxxxxxx> <20131221053032.GA3220@dastard> <52B6AE4D.5020104@xxxxxxxxxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
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!


<Prev in Thread] Current Thread [Next in Thread>