With metaluns and etc it quickly becomes far more complicated than one can measure reliably. At least at this point.

The goal here is to ensure Oracle’s reads are aligned to some power of 2 with the LUN.

The process I described exists due to old style legacy disk partitioning (cylinders/heads). Today, we rely on LBAs, and just treat the space linearly.

fdisk (and others) however still operates under legacy assumptions for disks > 32 GB, and thus tries to align on something that doens’t exist anymore (cylinders).

Thus we align on power of two on LBA under the assumption that the underling storage will be able to better serve us , and be able to better optimize it’s caching blocks internally .

It is very cool article thank you for sharing it with us. I do have few questions/doubts about the approach and the way to validate it.

– In Enterprise SAN infrastructure LUN-s are provided from Storage Backend to Oracle – consumer without any relatable information (I assume here please correct me if I am wrong) about physical lay out of the underlying disks. I mean that SAN infrastructure hides the information such us cylinders/sectors/etc as each LUN isn’t a separate physical disk anymore. It is combination of disks and stripe technology used by particular vendor (with hopefully their own optimization). By the time a LUN presented to Linux/fdisk (I assume) it is far way from being a simple disk. Therefore I even assuming that we making a right offset to avoid double IO in certain cases I would like to have some good method to verify my configuration (see second point)

– Let’s imagine we made a 16MB offset creating our partition. We made an assumption that it will help us to increase IO performance by 12%. Question is there any good way to validate our assumption? I would like to be certain that I am releasing a storage chunk to my production space consumers in best possible configuration. Could you think about a simple test to validate our suggested assumption? I am guessing that iostat couldn’t be used in that case as we are talking about lower level IO split on device driver layer or in case of SAN it is going to be hidden somewhere in IO backend controllers.

– It looks like the way you put the suggestion it applies to fdisk only. Most probably the other volume managers (like Veritas etc) might have the same issue however it should be checked separately (with vendor support etc).

– If the reason to introduce fdisk activity is “make explicit that something exists”, I would introduce an additional maintenance procedures for the technical stuff and would make sure that everybody aware about the configuration chosen and would go with direct device usage (/dev/sdc rather then /dev/sdc1) to avoid an additional IO layer (partition) and risks of loosing 12% of IO performance. Are there other reasons to use partitions? I assume here that fdisk doesn’t help to address devices permissions and naming issue.

Thank you in advance,
Yury

An other great page is the following:
http://insights.oetiker.ch/linux/raidoptimization.html

What would be great is a complete post on how to optimize the whole thing…

HW RAID -> Partitioning -> LVM -> File system option (Ext3 like stride, fs-type largefile4, etc)

About the following:

> Essentially, I “waste” 16 MBs, but gain aligned
> I/O for stripe width of up to 16 MB.”

Based on the following page, I suspect “stripe width” isn’t rightly used here…

“Stripe width refers to the number of parallel stripes that can be written to or read from simultaneously. This is of course equal to the number of disks in the array.”

http://www.storagereview.com/guide2000/ref/hdd/perf/raid/concepts/perfStripe.html

However, given what I know so far, 256k will be fine. Remembe we’re talking about saving ~760 kb here …