> [Put yourself in their shoes – If you reported an issue to your vendor and they responded “Who knows? It’s all outdated and you need to change your processes.” – what’s your reaction going to be?]
Perhaps a better reply would be to tell them you do know what?s happening, and for about the last decade or two, sponging physical disks use a variable number of sectors per track, so it?s not possible to report a correct CHS geometry. Some drives may be able to tell you their actual geometry if you issue the correct mode page request. My memory is geometry is generally broken up into zones, there is a list of LBA x to y has geometry z values.
If the goal is to pick a value for aligning partition start addresses, there are a couple of opinions on what the optimal value would be. You could report a value for heads and sectors per track such that the two multiplied give a appropriate alignment value. The classic problem with this is the the maximum disk size you can describe is vastly smaller than current drives, so setting H and S to their largest allowed values gave you the largest possible disk, which still is way smaller than current disks sizes, which is why we use LBAs now and not CHS.
CHS in it?s bios field width form, can?t come close to describing modern sizes of disks. CHS was originally used because it matched up with some control registers for an ancient IDE disk controller in the ?80s.
In general, disks know a lot more about how to optimize their own performance than naive software, so there is a good argument you should just treat the disk at a linear array of block addresses (and know the block size), and let the drive do any performance optimizing.
The partition alignment probably matters based on what RAID striping is applied, and one could view that some alignments are better for the RAID controller.
There also is the modern issue of Flash memory chunk sizes. Flash memory can?t be updated on 512/4096 by boundaries, so you should likely align a partition on a natural boundary of the flash block size. If you write a lot of chunks a lot smaller than the native block size, you get write amplification and it uses up the limited number of writes each flash block can do. Writing 512 bytes every 128K or so is probably a great way to wear out your flash drive. I don?t think OSs or file systems really know how to use write block sizes other than 512/4096 bytes, even though a value like 128K is likely a lot better for flash storage life. This is one argument of why flash storage should talk in terms of file I/O requests, not blocks. If you do file I/O requests to a device, it can optimize it?s performance and wear. It might for example use a write mostly file file system, and store up changes in NVRAM buffers until a full flash block can be written. This offhand seems way more optimal than what we do now.
A lot of storage is controlled by some complex storage controller, which may for example deal with blocks of some size unrelated to the physical disks. If you do write operations then span two storage controller blocks, it may give non-optimal performance. The virtual blocks you get from a complex storage controller (like from EMS/Netapp/etc), may report info about the optimal block alignment via mode pages.
Jan
