Milan,
since you mentioned it, maybe you could check, if I got this right
afterall :-).
md127 : active raid6 sda3[0] sdc3[3] sdd3[2] sdb3[1]
67119104 blocks super 1.1 level 6, 512k chunk, algorithm 2 [4/4] [UUUU]
bitmap: 0/129 pages [0KB], 128KB chunk
Sine chunk-size is 512k, we'll end up with 2MB stripes, carrying 1MB of
real data each, thus we wanna align the luks payload on 1MB boundaries
(well, any multiple of 1MB is fine anyway).
LuksDump Reports:
Payload offset: 4096, which would come down to 2MB which is a multiple of
1MB.
pvs +o pe_start reports a pe_start of 1MB PE Size is set to 1MB too, so at
all times, each PE starts stripe aligned.
xfs_info reports:
data = bsize=4096 blocks=2096640, imaxpct=25
= sunit=128 swidth=256 blks
---
since blocksize is 4KB, we end up with sunit of 128*4kb=512kb (chunk
size), and swidth acordingly 1mb (2 chunks of data in each stripe)
Does this look correctly?
Two things I'd like to ask, since they confused me:
What should be the md's device readahead, it is set to 2 MB (stripe size
including redundancy) does this seem right? if so, why is it, that it is
set to 1.5*stripesize for another md device? Does a typical setup set
readahead to 2*amount of real data within a stripe - this would explain
the readings I am getting.
The other thing: what does the value of algorithm (in /proc/mdstat)
designate? Do you know by any chance, I seem incapable of finding the
right place for a documentation on this.
Thanks for all your helpful replies.
Regards
-Sven
On Sat, July 18, 2009 12:08, Milan Broz wrote:
> Roscoe wrote:
>> On Sat, Jul 18, 2009 at 7:04 PM, Sven
>> Eschenberg<sven@xxxxxxxxxxxxxxxxxxxxx> wrote:
>>> Sorry for answering my own mail,
>>>
>>> I had a misconception there. I fired various values for dataalignment
>>> at
>>> cryptsetup and it always chose a value of n*DA >= 4096 sectors. So
>>> obviously 4096 sectors seems to be a lower bound I was not aware of.
>>>
>> You may be underestimating the space LUKS takes up. The PHDR is 592
>> bytes, but the keyslot sizes depend on the number of AFstrips and the
>> keysize. If one us using AES-256 with XTS and 4000 strips, then the
>> space LUKS takes up will be around 2 megabytes.
>
> Exactly, moreover keyslots are aligned to 4k blocks too.
>
> You can check the real data offset in luksDump (Payload offset).
>
> The --align-payload takes argument in sectors (512 bytes) and the real
> data alignment is rounded up to multiply of that.
>
> For example, default alignement is 4k with 128bit key you get:
> data offset 1032 sectors
>
> With --align-payload=512 you get data offset 1536 (3 * 512).
>
> Milan
>
> p.s.
> BTW For LVM over LUKS I mostly use 4MB (Which always aligns to my
> underlying SSD drive,
> the same applies to underlying RAID and chunk/stripe size)
>
> - properly align partition (use sectors, not default: fdisk -u, or use
> parted)
>
> - align data on LUKS drive (e.g. cryptsetup luksFormat ...
> --align-payload=8192 to align to 4MB)
>
> - pvcreate --dataalignment 4M to align PV to 4M offset, all LVs will be
> aligned automagically when created (option available in recent lvm2)
>
>
> ---------------------------------------------------------------------
> dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/
> To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx
> For additional commands, e-mail: dm-crypt-help@xxxxxxxx
>
>
---------------------------------------------------------------------
dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/
To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx
For additional commands, e-mail: dm-crypt-help@xxxxxxxx
