Seems you didn't read the article either, or the parent. I was discussing the reason why SSD manufacturers aren't using special MTD drivers anymore, and the reason they don't is because wear-levelling generally gets done in the MTD driver if there is a simplistic flash controller behind it (although you could do it in the controller, that makes the
The real problem is Linux uses CHS values (fake as they may be) in the block layer. Everywhere. And the partitioning tools do. And the RAID tools do by proxy.
ext4 has absolutely no idea what the "natural" alignment of the disk blocks and how they fit in a "cylinder" is because there's no decent way to find out based on CHS values which are fixed up and hardcoded inside the block layer.
You can find out how big a "physical" block is (512, 2048, 2352, 4096..), but 100% of available SSDs return 512 and a bunch of fake CHS all for compatibility's sake. CHS just doesn't work anymore and the compatibility means more fake CHS values are being implemented and dropped on top of the LBA addressing scheme.
If Linux or any other OS had any way of finding out where the natural alignment stood then regardless of where the partition is created (thus moving the problem away from some userspace tools which all get updated independently) then the filesystem can be created to take advantage of that alignment.
If the partition is created through "fake" CHS values then performance would suffer if the filesystem isn't aligned. This is the problem right now, filesystems assume that the start of the partition is naturally "cylinder" aligned. With a 128k erase block and CHS "cylinder" alignment with a 4k block size on the filesystem you could be pretty far away from well-aligned. If it knew that it had to align it's data structures then it doesn't have to make assumptions about the partitioning scheme. Let's be honest; there are more partitioning schemes than MBR. What about GPT or RDB? BSD slices?
http://www.ipnom.com/FreeBSD-Man-Pages/fdisk.8.html
I love this little snippet;
If you hand craft your disk layout, please make sure that the FreeBSD slice starts on a cylinder boundary. A number of decisions made later may assume this. (This might not be necessary later.)
So, it may be necessary or not. BSD slices are not naturally aligned - as defined - on cylinder boundaries, they use sector size only. Some tool such as fdisk tries to handle this for you. But the values the disk and the kernel pass back are just not realistic (255 heads, 63 cylinders...) and do not reflect ANY disk.
Since you can't change the 255/63 value passed in by the disk or hardcoded in the block layer, plus cylinders and heads make zero sense on a flash drive (or a ramdisk or a virtualized block layer) why not a new ATA command set which reports the true natural alignment of the disk, with reasonable values which can be used to optimize performance, well away from the compatibility values, that the filesystem can get (as it gets the sector size) and rely on for the best performing filesystem on that media?