[linux-lvm] does alignment work out of the box now

[linux-lvm] does alignment work out of the box now

[Philippe Cerfon]

Hi.

I recently stumbled across the whole alignment thingy and read many
email threads and so how to actually do it, but still I guess I do not
fully understand it ^^
It seems however that many works out of the box already, so may I ask
for confirmation whether this is the case in my scenarios.

I'll have basically two setups:
a) SSD -> lvm2 -> dm-crypt/LUKS -> filesystems (ext4, btrfs)
b) 4xHDD -> mdadm/raid6 -> lvm2 -> dm-crypt/LUKS -> filesystems (ext4, btrs)

Now AFAIK there are several things that have to be aligned:
- To the single physical blocks thorugh all layers, so that I e.g.
don't write actually two physical blocks on my SSD when only writing
one logical
- To the stripe sizes of the RAID
- To the extents of LVM
Right?


My kernel is 2.6.34, my lvm2 is 2.02.66, my mdadm is 3.1.2 my
cryptsetup/dm-crypt/LUKS is 1.1.2, my e2fsprogs is 1.41.12.
Please forgive me if md/dm-crypt/filesystem related questions are a
little bit off topic here.


a) AFAIK mdadm automatically determines a aligned stripe size (I guess
a multiple of the physical block size of my HDDs), right?

b) I have the following in my lvm.conf
sysfs_scan = 1
md_component_detection = 1
md_chunk_alignment = 1
data_alignment_detection = 1
data_alignment = 0
data_alignment_offset_detection = 1
Am I right with the following?
- This will automatically get the underlying block size from BOTH the
physical device (SSD) OR the md device (raid6) and "use" the same.
- And it will automatically detect the stripe size, right?
Does this now mean that the extent size is automatically choosen to be
a multiple of the blocksize PLUS the stripe size?
And does it mean that the data-part of PVs is automatically algined to
the blocksize and the stripe size?

When I now create a snapshot, is the chunksize also automatically
aligned as well as the chunks themselves? Or do (how) I have to do
this manully? I guess by using a multiple of the block size _and_
stripe size.


c) Do the LVs themselves publish that info (block size, extent size
and so on) to upper layers (in my case dm-crypt) so that those layers
can choose the right values?

d) I think cryptsetup is able to automatically detect those stuff in
the most recent versions, but I'm not sure if this only works when
dm-crypt is directly on a physical block device or also when it is on
top of mdadm->lvm2

e) Does the filesystem also get the blocksize automatically? Or do I
have to specify it via mke2fs -b <blocksize>

f) I've seen that mke2fs also has the options -f fragments,
stride=stride-size and stripe-width=stripe-width but I have no idea at
all whether and how I have to set them.


g) There are some howtos which say one should create PVs on partitions
rather than whole devices, while other say it's fully ok to have them
directly on the device.
But I think this must also have an impact on all the alignment as I
have 63 more 512 sectors, right? So how should I best do this?


Thanks for your help,
Philippe.


btw: I've already read all the recent posts here regarding alignment,
including that one:
http://osdir.com/ml/linux-lvm/2010-03/msg00032.html
I read $ cat /sys/block/sda/sda1/alignment_offset
0
which I don't understand. I thought having the 63 sectors partition
table in the beginning should destroy the alignment?

[linux-lvm] does alignment work out of the box now

[Philippe Cerfon]

[-- Attachment #1: Type: text/plain, Size: 3286 bytes --]

Hi.

I recently stumbled across the whole alignment thingy and read many
email threads and so how to actually do it, but still I guess I do not
fully understand it ^^
It seems however that many works out of the box already, so may I ask
for confirmation whether this is the case in my scenarios.

I'll have basically two setups:
a) SSD -> lvm2 -> dm-crypt/LUKS -> filesystems (ext4, btrfs)
b) 4xHDD -> mdadm/raid6 -> lvm2 -> dm-crypt/LUKS -> filesystems (ext4, btrs)

Now AFAIK there are several things that have to be aligned:
- To the single physical blocks thorugh all layers, so that I e.g.
don't write actually two physical blocks on my SSD when only writing
one logical
- To the stripe sizes of the RAID
- To the extents of LVM
Right?


My kernel is 2.6.34, my lvm2 is 2.02.66, my mdadm is 3.1.2 my
cryptsetup/dm-crypt/LUKS is 1.1.2, my e2fsprogs is 1.41.12.
Please forgive me if md/dm-crypt/filesystem related questions are a
little bit off topic here.


a) AFAIK mdadm automatically determines a aligned stripe size (I guess
a multiple of the physical block size of my HDDs), right?

b) I have the following in my lvm.conf
sysfs_scan = 1
md_component_detection = 1
md_chunk_alignment = 1
data_alignment_detection = 1
data_alignment = 0
data_alignment_offset_detection = 1
Am I right with the following?
- This will automatically get the underlying block size from BOTH the
physical device (SSD) OR the md device (raid6) and "use" the same.
- And it will automatically detect the stripe size, right?
Does this now mean that the extent size is automatically choosen to be
a multiple of the blocksize PLUS the stripe size?
And does it mean that the data-part of PVs is automatically algined to
the blocksize and the stripe size?

When I now create a snapshot, is the chunksize also automatically
aligned as well as the chunks themselves? Or do (how) I have to do
this manully? I guess by using a multiple of the block size _and_
stripe size.


c) Do the LVs themselves publish that info (block size, extent size
and so on) to upper layers (in my case dm-crypt) so that those layers
can choose the right values?

d) I think cryptsetup is able to automatically detect those stuff in
the most recent versions, but I'm not sure if this only works when
dm-crypt is directly on a physical block device or also when it is on
top of mdadm->lvm2

e) Does the filesystem also get the blocksize automatically? Or do I
have to specify it via mke2fs -b <blocksize>

f) I've seen that mke2fs also has the options -f fragments,
stride=stride-size and stripe-width=stripe-width but I have no idea at
all whether and how I have to set them.


g) There are some howtos which say one should create PVs on partitions
rather than whole devices, while other say it's fully ok to have them
directly on the device.
But I think this must also have an impact on all the alignment as I
have 63 more 512 sectors, right? So how should I best do this?


Thanks for your help,
Philippe.


btw: I've already read all the recent posts here regarding alignment,
including that one:
http://osdir.com/ml/linux-lvm/2010-03/msg00032.html
I read $ cat /sys/block/sda/sda1/alignment_offset
0
which I don't understand. I thought having the 63 sectors partition
table in the beginning should destroy the alignment?


      

[-- Attachment #2: Type: text/html, Size: 3948 bytes --]

Re: [linux-lvm] does alignment work out of the box now

[Stuart D. Gathman]

On Wed, 30 Jun 2010, Philippe Cerfon wrote:

> g) There are some howtos which say one should create PVs on partitions
> rather than whole devices, while other say it's fully ok to have them
> directly on the device.
> But I think this must also have an impact on all the alignment as I
> have 63 more 512 sectors, right? So how should I best do this?
> 
> I read $ cat /sys/block/sda/sda1/alignment_offset
> 0
> which I don't understand. I thought having the 63 sectors partition
> table in the beginning should destroy the alignment?

I can answer this one.  Using no partition table makes alignment
slightly easier, but is dangerous if the disk is ever seen by another
OS - which may think it is unformatted and do something nasty.  On
the other hand, the partition types LVM and RAID simplify reliable
booting (especially for software RAID).

When using a parition table, it must be created with a size that doesn't
destroy alignment - e.g. 128 or 256 sectors.  This is a lot of wasted space
for the useful byte (the partition type), but is trivial compared to 
disk sizes these days, and lets other Wintel OSes know there is data
on the disk.

My rule of thumb is that I skip the partition table for permanent local
LVM drives unless the drive also contains software RAID or a /boot partition.

-- 
	      Stuart D. Gathman <stuart@bmsi.com>
    Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.