VMware Cloud Community
donikatz
Enthusiast
Enthusiast
Jump to solution

Aligning Linux VM

As we know, EMC Clariion SAN recommended alignment offset is 128 blocks (64K). We've been aligning Windows VMs for a long time, but I'm just now going back and fixing our old RHEL templates to be fully aligned. I added a new disk and used gparted to copy the boot partition from sda1 to sdb = sbd1, setting it to NOT round to the nearest cylinder and to leave 1 MB free space preceding (= 2048 offset, a multiple of 128/64). I then copied the other partitions, reinstalled grub, etc. Everything boots & looks good. Routine stuff. However, I notice that fdisk now warns "Partition 1 does not end on cylinder boundary." Is this just the expected warning because it's not rounded to what it thinks are the cylinders and can therefore safely be ignored? Or am I missing a necessary step/logic in my process? Thanks!

0 Kudos
1 Solution

Accepted Solutions
tekka
Enthusiast
Enthusiast
Jump to solution

fdisk by default reasons by cylinder in its output.

If you align to 128, you are probably ending your partition at the middle of a cylinder. And the next one will begin inside the same cylinder, giving the (false) warning message.

If you run fdisk with the -u switch (eg. fidsk -lu / dev/sda ) you will instead get the output based on sectors, and you will see that the first partition ends at sector xxx while the next begins at sector xxx+1.

This is the important thing.

I asked about the next partitions in other thread without certian answers, but I'm sure it is the correct approach to align also those.

My lines in kickstart, just to be perfect as of alignment directives are kind of these, inserted inside the %pre section:

(/boot of 100M and then a PV of the remaing disk space; blank lines are actually return commands for fdisk...)

  1. clear mbr

dd if=/dev/zero of=/dev/sda bs=512 count=1 2>>$LOGFILE

fdisk /dev/sda << -TXT >> $LOGFILE 2>&1

n

p

1

+100M

x

b

1

128

r

n

p

2

t

1

8e

w

-TXT

SECSIZE=$(fdisk -lu /dev/sda | grep sda2 | awk '{print $2}' 2>> $LOGFILE)

export NEWSECSIZE=$(expr \( $SECSIZE / 128 + 1 \) \* 128 2>> $LOGFILE)

fdisk /dev/sda << -TXT >> $LOGFILE 2>&1

x

b

2

$NEWSECSIZE

r

w

-TXT

Then inside the section related to partitioning I have

part /boot --fstype ext3 --onpart=sda1

part pv.01 --onpart=sda2

volgroup VolGroup01 pv.01

ecc for defining logical volumes.

Bye,

Gianluca

View solution in original post

0 Kudos
6 Replies
donikatz
Enthusiast
Enthusiast
Jump to solution

Trying another way: Rather than using gparted, I decided to just use fdisk to create a new partition with starting block 128. fdisk now reports "Partition 1 has different physical/logical beginnings (non-Linux?): phys=(0, 1, 1) logical=(0, 2, 3)". Same question: Is this the expected warning because of the custom offset, or is something incorrect? Thanks

0 Kudos
donikatz
Enthusiast
Enthusiast
Jump to solution

Loving this whole monologue thing... 😛

So I decided to create a NEW new disk and now the fdisk alignment method doesn't result in any "different physical/logical beginnings" errors. So all looks good there. Not sure what the difference was. Anyhow...

One more question:

To align the second partition on a drive, I assume I should set the starting block to just be the next multiple of 128? For example, if the next avail block after partition 1 is 224910, I would instead set partition 2 to start at 225024 (divisible by 128). Right? Thank

0 Kudos
tekka
Enthusiast
Enthusiast
Jump to solution

fdisk by default reasons by cylinder in its output.

If you align to 128, you are probably ending your partition at the middle of a cylinder. And the next one will begin inside the same cylinder, giving the (false) warning message.

If you run fdisk with the -u switch (eg. fidsk -lu / dev/sda ) you will instead get the output based on sectors, and you will see that the first partition ends at sector xxx while the next begins at sector xxx+1.

This is the important thing.

I asked about the next partitions in other thread without certian answers, but I'm sure it is the correct approach to align also those.

My lines in kickstart, just to be perfect as of alignment directives are kind of these, inserted inside the %pre section:

(/boot of 100M and then a PV of the remaing disk space; blank lines are actually return commands for fdisk...)

  1. clear mbr

dd if=/dev/zero of=/dev/sda bs=512 count=1 2>>$LOGFILE

fdisk /dev/sda << -TXT >> $LOGFILE 2>&1

n

p

1

+100M

x

b

1

128

r

n

p

2

t

1

8e

w

-TXT

SECSIZE=$(fdisk -lu /dev/sda | grep sda2 | awk '{print $2}' 2>> $LOGFILE)

export NEWSECSIZE=$(expr \( $SECSIZE / 128 + 1 \) \* 128 2>> $LOGFILE)

fdisk /dev/sda << -TXT >> $LOGFILE 2>&1

x

b

2

$NEWSECSIZE

r

w

-TXT

Then inside the section related to partitioning I have

part /boot --fstype ext3 --onpart=sda1

part pv.01 --onpart=sda2

volgroup VolGroup01 pv.01

ecc for defining logical volumes.

Bye,

Gianluca

0 Kudos
donikatz
Enthusiast
Enthusiast
Jump to solution

Thanks Gianluca, you've confirmed my thoughts exactly!

I also read an interesting idea in the OCZ forums: setting custom aligned heads and sectors, i.e.:

fdisk -H 8 -S 16 /dev/sda

This would align everything to 64KB (128) and nothing else would need to be done other than starting sda1 with offset 2. What do you think of that?

http://www.ocztechnologyforum.com/forum/showthread.php?p=373226#post373226

Thanks again

Message was edited by: donikatz

0 Kudos
donikatz
Enthusiast
Enthusiast
Jump to solution

Hmm, tried it out and it seems to work (starts sda1 on 128 without creating a custom offset), but it's just asking for trouble. Utilities like gparted expect 255/63 and get confused. Even fdisk gets confused and now thinks a 10.25 GB disk is 11 GB and doesn't automatically know when sdb1 ends and sdb2 should begin (asks to start with sector 1 again). I think it's best to stick with a normal config + manual partition offsets.

0 Kudos
mcowger
Immortal
Immortal
Jump to solution

Have you actually tested the performance difference of an aligned vs. unaligned VM?

We were unable to measure a performance difference between them and so we said screw it.






--Matt

VCP, vExpert, Unix Geek

--Matt VCDX #52 blog.cowger.us
0 Kudos