SmartArray actual storage geometry - Partition alignment issue

Guys,

I'm currently creating a logical drive on a P812 SmartArray seated inside a DL180g6, that has to bee partitionned in 3 parts. This RAID5 LD is made up of six 2.5'' 1TB SATA drives, for a total of roughly 5TB (4.6TB according to hpcucli).

I'm wondering about the best alignment for the 3 partitions I have to place there, so I switched on my calculator and started some cylinder computations. But searching for the related input parameters, I'm facing something a bit odd :

So who's right, who's wrong ? Further, I made my computations using both values, and when I tried to create my very first partition, leaving the 1st cylinder free, parted complains that alignment is not the best possible when it is supposed to be aligned on a cylinder boundary.

1st try, 63 sectors per track as per fdisk's advice :

(parted) mkpart primary 16065s 2147488874sWarning: The resulting partition is not properly aligned for best performance.

2nd try, 32 sectors per track as per hpacucli's recommendation:

(parted) mkpart primary 8160s 2147483519sWarning: The resulting partition is not properly aligned for best performance.

Has anyone already experimented this kind of stuff with SmartArray cars ? I searched for HP white papers speaking about that but nothing really valuable...

Re: SmartArray actual storage geometry - Partition alignment issue

With modern disks, the C/H/S geometry is essentially fictional. The real geometry is more complex than that: for example, the tracks near the outer rim of the disk typically contain more sectors than the inner tracks near the spindle.

If your Linux distribution includes the "lsblk" command, then "lsblk -t" might tell you useful information about the alignment requirements of the underlying hardware. (On SSDs, "lsblk -D" might be useful too.)

I run "lsblk -t" on a BL460c Gen8 blade; apparently its controller really likes to do things in chunks of 256kiB:

Re: SmartArray actual storage geometry - Partition alignment issue

Hi Matti!

Thanks for your reply. Interesting. I had already read that block size had changed up to 4k since 2010 I bielieve (Seems like SATA keep reporting 512B lock size though... At least that's what I see in /sys/block...), but I didn't know about this variable sector/track feature.

Re: SmartArray actual storage geometry - Partition alignment issue

Trying to use the C/H/S geometry to achieve a particular alignment is tricky and may be futile in some cases. The best you can do at the partitioning level is usually treating the disk as a single long stream of LBA blocks and setting the partition start/end points to exact multiples of whatever is optimal for your disk/SSD/SAN model, RAID controller or stripe size. If you aren't sure, multiples of 4kiB, 16 kiB, 64 kiB or 128 kiB are usually good guesses.

With Linux fdisk, that means switching off the DOS compatibility mode, if your fdisk enables it by default, and choosing "sectors" as partition size units. ("fdisk -c=nondos -u=sectors"; newest Linux fdisk versions may do that by default.)

This way you can set partition start/end points exactly where your alignment requirements dictate: fdisk won't place artificial obstacles to you by modifying your values to conform to some DOS-compatible (fictional) C/H/S geometry. It will populate the C/H/S fields of the partition table with appropriate LBA placeholder values, and only the LBA of the partition start and the total number of sectors will be meaningful.

If your disk is larger than 2 TiB in size, I think the current recommendation is to use a GPT partition table instead of the traditional PC-style partition table if possible. The traditional partition table has a hard design limit at about 2 TiB: at that point, the LBA values become too large to be stored in the 32-bit fields in the traditional partition table.

The GPT has only LBA values in it, so there is not even any way to specify a particular C/H/S geometry any more. On the other hand, it has 64-bit fields for the LBA values, which should be good enough for a while.

If your hardware, OS and partitioning tool are new enough, there are standard ways for the hardware to communicate its alignment requirements to the software. The "lsblk -t" command is part of that.

If your hardware has a particularly "coarse" alignment requirement (say, 128kiB or more), it might be hard/wasteful to align the first partition on the system disk optimally. But the first partition is often /boot, which experiences major read operations essentially only at boot time and writes only when kernel or bootloader updates are installed, so you might not care about it being non-optimally aligned.

Re: SmartArray actual storage geometry - Partition alignment issue

Hi, Matti !

Thanks for these precisions. I have played around with lsblk command, along with a couple of others that the man pages led me to, interesting, and finally adopted the Microsoft alignment convention of 1MB. Since my RAID stripes are 256kB, at least it's aligned on that, and then I believe there's not much more I can do...