Not sure I follow you since the guide tells you to align partitions. They’re not saying that you have to have partitions in the first place.
If I don’t have partitions there is nothing to align.
What is the difference between aligning a partition and not having one in the first place except less hassle ? Am I missing something here ?

Besides, as per my discussion with an EMC engineer…
Quote :
“There is absolutely no guarantee that any i/o will be aligned with our stripes. Clariion does not offer true Raid-3 in which all i/o’s are forced to read exactly the same full stripe or nothing at all. All the alignment tools do is make sure the beginning of the filesystem is aligned with the lun’s stripes but i/o’s in general are not aligned”
End quote

In other words you can align your partitions all you want you cannot prevent further disk crossing afterwards.
I’m still discussing with them why they say that but at the same time put so much emphasis on that one-time alignment.

1. Why would I possibly want to create a partition table for a disk that will become a PV ?????
I have always created PV’s on whole disks (pvcreate /dev/sdb) and that has been working just fine.

2. Even without LVM why bother with a partition ?
As far as I can see partitions do nothing but add problems (such as the alignment offset) and adds no value whatsoever. The only reason to partition is if you need to slice a disk into smaller disks (like the installer does with /boot and / etc…) That’s it.
Other than that partitions have no purpose.
Why create a partition that is as large as the entire disk when I want to use the entire disk anyway ?

[root@vm1 astuck]# /sbin/mkfs -t ext3 -j -m0 /dev/sdb
mke2fs 1.39 (29-May-2006)
/dev/sdb is entire device, not just one partition!
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
1310720 inodes, 2621440 blocks
0 blocks (0.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=2684354560
80 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632

Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 26 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.

Now I can easily expand the virtual disk on esx and run resizefs on /dev/sdb. No partition ever needed.

I noticed that indeed the same normal formatting is going on in the guest VMs here – an offset of 63 bytes for the first bit of data. Thinking about it, this could very well make for similar performance issues like you noted. Having everything in the guest offset by 63 bytes means that the host has to read 2 blocks for every 1 block the guest wants and then re-create a new virtual block of data (I’m assuming). This could be the cause of the poor disk i/o I’m encountering (although I have heard that this wasn’t a problem in VMWare Server 1.x – but I haven’t done any testing).

Running dumpe2fs on the host to quickly get the formatted block size of the disk the guest VM’s are on and then offsetting the first block of data in the guest disk to match might be the trick. I’ll be giving this a try and see how it turns out. Hopefully it solves my problem!

SAN/ESX/Linux/LVM is the most common OS & disk setup I am doing lately. When I get to my Linux VM install, I am using a Rescue Disk to create my disk partitions first, including LVM partitions. I then reboot into install mode, and go through the normal OS install, including creating the LVM volume groups.
Is there a problem with this process? Is the LVM I/O aligned in this case?

VMFS3 Partitioning – — For best performance, use the VI Client or Web Access to set up your VMFS3 partitions, rather than using the ESX Server installer. Using the VI Client or Web Access ensures that the starting sectors of partitions are 64K‐ aligned, which improves storage performance.