DM-Crypt Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Milan Broz <gmazyland@gmail.com>
To: Karol Babioch <karol@babioch.de>
Cc: dm-crypt@saout.de
Subject: Re: [dm-crypt] Reconsidering default options for cryptsetup-reencrypt
Date: Fri, 23 Nov 2012 09:49:41 +0100	[thread overview]
Message-ID: <50AF38A5.7040306@gmail.com> (raw)
In-Reply-To: <50AEF7B3.4000807@babioch.de>

On 11/23/2012 05:12 AM, Karol Babioch wrote:
> However I would argue that enabling direct I/O should be faster on most
> systems considering that usual block devices are probably quite big - at
> least compared to "normal" files and reencrypting the device is a purely
> consecutive process.

But unfortunately your assumption is not correct. Not only direct hw is used,
many times you are running container from file (namely for virtual machines).

I have no problem with changing defaults but I selected current defaults
because of testing quite a lot of systems. But everything is configurable
(and you can even restart reencryption with changed options.)

> Running some tests I could confirm my assumption. In my case where I've
> got a hardware RAID with read ahead enabled, it makes at least a
> difference of about 10%.

Differences can be even 30-40% but both directions, depends on system.
(For different block sizes even more.)

So not only direct io, also block size and sometimes enabling fsync helps too.

> That said I think the bigger influence is the choice of the right block
> size. By choosing the right block size I could double the speed. As
> already said above I think it probably is quite hard to get this one
> right automatically for each and everyone, because it depends upon
> various caches involved. From a theoretical stand point it probably
> should be about half the size of the smallest cache involved. I'm not
> sure whether it makes any sense (or is even possible) to probe for these
> things, but considering the speed enhancement of - at least in my case -
> 100%, there should probably be something done about it.

Just few use cases I tried
- notebooks with SSD or rotational disks
- high speed PCIe SSD array
- direct rotational disk
- MD arrays of rotational disks
- external storage (with FC multipath betwen it)
- iSCSI
- VM with file backend (VMware and KVM)
...

Try it, you will see that common default doesn't work for some of these.

Anyway, defaults can be changed, we can add some heuristic or benchmark
but I would like to see that tool tested more first.

Milan

      parent reply	other threads:[~2012-11-23  8:49 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-23  4:12 [dm-crypt] Reconsidering default options for cryptsetup-reencrypt Karol Babioch
2012-11-23  6:07 ` Arno Wagner
2012-11-23  9:00   ` Milan Broz
2012-11-23  9:27     ` Arno Wagner
2012-11-23  9:42       ` Milan Broz
2012-11-24 17:01   ` Sven Eschenberg
2012-11-24 20:59     ` Milan Broz
2012-12-03  0:27       ` DarKRaveR
2012-11-23  8:49 ` Milan Broz [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50AF38A5.7040306@gmail.com \
    --to=gmazyland@gmail.com \
    --cc=dm-crypt@saout.de \
    --cc=karol@babioch.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox