[dm-crypt] Wrong behavior?

Sven Eschenberg sven at whgl.uni-frankfurt.de
Wed Jul 14 13:39:17 CEST 2010

Hi Milan,

On Wed, 2010-07-14 at 09:58 +0200, Milan Broz wrote:
> On 07/14/2010 12:17 AM, Sven Eschenberg wrote:
> > Well, yet it gives me the chance to use the RNG of my choice, might it
> > be a HW-RNG in a TPM or chipset, in software of my choice or
> > whatsoever ;-). Well, maybe I would want to play with own RNGs and no, I
> > am not gonna use any PRNG using linear congruences for that matter :-).
> You can add second keyslot using keyfile and remove former afterwards as workaround.
> But if you want to do such low level operations, maybe you want to use dm-crypt
> directly, without luks...

Yes, since I usually use 2 key slots and 2 keys stored at different
locations (since one keystore might get corrupted) I can setup up with
some initial passphrase, set the second key to slot 1 and afterwards the
primary to slot 0. No worries there - Just saying, it should be fixed
whenever possible.

> > Humm, I was just thinking, obviously cryptsetup uses the readahead of
> > the device as a measure for alignment.
> No, readahead has nothing to do with device alignment. We are using device topology
> as defined by stacking device, this approach is now supported by all
> tools (fdisk & partitioning toos, lvm2, mdadm, cryptsetup).
> If topology IOCTLs are not supported (kernels <2.6.32 iirc) it simply defaults
> to alignment of 4k.
> MD of course provides proper value according to configured mode (chunks etc).
> Readahead is set the same as underlying device, readahead is dynamic property
> of device (you can change it using blockdev --setra anytime) while alignment
> is calculated during device format and cannot be changed later.)
> Milan

Is there any 'easy' way to access this information. specifically I am
interested, why md would report a 6144 sectors alignment on my 4 disk
raid5 with 512 kb chunks instead of 3072.



More information about the dm-crypt mailing list