This only counts for mechanical disks, not SSD's. You can asume the partitions to the left are on the inside if they are created first. To be sure though, especially when you're redoing your work and recreating and deleting partitions, you can use a free/open source partitioning tool with a better graphical view, like GpartEd.
Also, if speed is important and you're willing to compromise some disk space, consider 64K allocation unit size.
If you're not into recklessly wasting space for a little more speed, you can still consider using larger allocation units but you'd have to be more considerate. 64K would suit volumes where you'd store files that are typically a few MB or larger in size. If you're storing large amounts of smaller files, try and pick an allocation size that averages around the file size, if possible.
Basically, if you pick 64K with too many small files, each file will take up 64K regardless of its own (smaller) size. With 30,000 files and wasting half of each allocation unit, you're wasting twice the space you would with 32K allocation units. Theoretically, it might be faster but that's not a good trade off IMO. But let's say its mostly videos and large music files on there, go with 64K units.
The reason is simply that the OS caches allocation tables. It's basically a database with records and pointers. If you have a large volume of 1TB with the default (4K) allocation unit size, I estimate you have around 200 million allocation units. With 64K allocation units that would be roughly 12,5 million units for the OS to keep track of. That's a lot less which can lead to a faster volume.
This practise is diminishing with faster pc's but I still believe its good practise and something to consider if speed is important. The OS still needs less memory with larger units and less CPU cycles to crawl through all the allocation units.