It is often believed that disc partitions have to be aligned to cylinder or track boundaries. This is not in fact true and never really has been. There are alignment considerations for disc partitions, but they have nothing to do with cylinders, and they aren't mandatory. Operating systems will still work with misaligned partitions, just more slowly for some (not all) disc unit models.
The idea that disc partitions have to aligned to cylinder boundaries is nonsense on its face. Millions of people have had discs where the first primary partition began on track zero, sector one, head one with no ill effect whatsoever on operating systems from MS-DOS through Windows NT to OS/2. That was, after all, the default that fdisk/Disk Manager on those operating systems used for almost two decades. At best, the purported alignment requirement would have been a track alignment, with all partitions starting at sector one (Sectors are numbered from one, remember.) of any given track.
But this is not true, either. No version of any operating system has actually required this. Even MS-DOS was quite happy to have disc partitions starting at sectors other than 1. The only things that have required this have been disc partitioning utilities. There's been a bit of circular logic about this. The disc partitioning utilities enforced the requirement because their authors thought that it was a requirement, but people only thought that it was a requirement because fdisk and the like enforced it. It was what the partitioning utility programs enforced — so the logic went — so it must have been a restriction. In fact it never was, and no operating system itself has any trouble with this.
The idea of track alignment is daft anyway. It's pointless because it doesn't align things to any valid boundary on the disc unit itself. There's no performance or other benefit, because the physical layout of the partitions on the disc will not be aligned to the actual physical tracks on the disc by aligning them to the software-visible track size.
The "tracks" that system softwares see at the ATA command register level aren't actually the real tracks on the disc itself, and haven't been since the advent of zoned bit recording (ZBR) in the early 1990s. Tracks are not, in fact, equally sized across the whole disc with ZBR; even though that's how discs are presented to software via the (old) cylinder+head+sector I/O command interface for ATA disc units.
Unlike ATA, the SCSI command level has always operated in terms of logical block numbers, and not in terms of a cylinder+head+sector system in the first place. In the SCSI world, from the start the idea that system software necessarily even knew where the physical track boundaries were was incorrect. Indeed, PC firmwares for SCSI hard discs have to invent disc geometries, largely from thin air, for the benefits of old PC/AT and PC98 firmwares and operating systems that expect discs to be addressed, at the disc unit I/O command level, in terms of a three-dimensional CHS geometry. Alignment to a geometry that's just made up anyway by the machine firmware is just pointless.
With much fanfare, Microsoft finally eradicated enforcement of this entirely useless and pointless notion from the Windows NT Disk Manager, in 2008 (i.e. with the releases of Windows Vista Service Pack 1 and Windows Server 2008). Indeed, for years before that, since 2003, it had been recommending to Exchange Server and Microsoft SQL Server administrators that they use diskpart to align disc partitions to 4KiB multiples for performance reasons. (Some of the performance reasons given in early years were spurious, since they were based upon the erroneous premise that software-visible track boundaries were also physical track boundaries. But the end result, in light of later hardware developments, was right despite that.)
Linux has not caught up. As of 2011, the fdisk utility in Linux still complains about partitions not aligned to track boundaries. As such, it is strongly recommended to not use the Linux fdisk utility, and to use a partitioning tool that is more in step with the modern world, such as Rod Smith's gdisk, which has the incidental benefit of supporting the modern EFI disc partitioning scheme too.
There is a disc partition alignment rule that does reflect the actual hardware. It is the rule that partitions be aligned to 4KiB boundaries. This rule only makes sense for some hard disc models, however.
In some hard disc models, the internal sector size has been increased from 0.5KiB to 4KiB. At the I/O command level, as system softwares access the disc, the sector size is still 0.5KiB, however. Such discs are known as "512 byte emulation" discs. (It is intended that there will also be "4KiB native" discs, where the sector size at the I/O command level is also 4KiB. But since as yet very few operating systems can cope with sector sizes other than 512 bytes at the ATA/SCSI I/O command level, such discs can only be used by a small number of people right now, and there's simply not a large market for disc manufacturers to sell to.)
What happens on such "512e" discs is that whenever the operating system or the firmware reads a 0.5KiB sector, the disc unit itself is actually reading a whole 4KiB and handing the firmware/operating system the appropriate one-eighth; and whenever the firmware/operating system writes a 0.5KiB sector, the disc unit is actually reading a whole 4KiB sector, modifying one eighth, and writing the whole 4KiB back again.
This may seem like a performance killer, as every I/O operation is, under the covers, eight times its apparent size. Fortunately, there's a way to hide the performance cost. This takes advantage of the fact that many operating systems like to do most of their I/O in 4KiB multiples anyway. All paging I/O on x86 operating systems is done in 4KiB multiples, for example, and many operating systems, including Windows NT and Solaris, use the paging mechanism for ordinary file I/O too. So the operating system will usually be reading and writing (a multiple of) eight 0.5KiB sectors in a single I/O operation.
So it's simply necessary to ensure that those eight 0.5KiB sectors are contiguous and aligned to an actual 4KiB sector on the disc. The "natural" I/O boundaries used by the operating system must align with the internal, hidden, 4KiB boundaries of the physical disc. The eight 0.5KiB sectors in the I/O command must not span two or more 4KiB physical sectors; but must be exactly one 4KiB sector, and in the right order within that sector.
It's worth noting that several people have measured the performance hit that not aligning partitions to 4KiB on "512e" discs causes, and been surprised that it is quite large. Ironically, many of their figures have been lower than the eightfold increase that there theoretically should be, for every 0.5KiB request turning into a 4KiB request under the covers, and they should have been surprised at how small the performance hit was. The reason that the performance hit is lower in practice is that many operating systems try to do what BSD folk call (in the context of paging I/O at any rate) klustering: They bunch up a set of multiple, individual, but contiguous, disc block I/O requests into a single request that encompasses all of the blocks in one I/O command sent to the disc unit. This reduces the amount of the underlying 4KiB-per-sector I/O request, that the disc itself then does, that is wasted, and thus ameliorates the performance penalty.
The way that this 4KiB alignment is achieved is threefold:
Partitions are aligned to 4KiB boundaries relative to the start of the entire disc. The start, and end, of every partition is an integral number of 4KiB sectors from the start of the entire disc.
On-disc data structures within a volume are aligned to 4KiB boundaries relative to the start of their containing partitions. If a disc volume format employs concepts such as "zones", "cylinder groups", and so forth, as volume formats with BSD Unix influences such as UFS and EXT2/3/4 do, they must be integer multiples of 4KiB in size. Neither FAT nor NTFS have such concepts. But FAT volumes similarly have to ensure that the total size of the FATs and reserved sectors at the beginning of a volume is an integer multiple of 4KiB, so that the data clusters following them are aligned to 4KiB multiples.
The volume's space allocation unit ("cluster") size is an integer multiple of 4KiB. You'll find that Windows NT's tools nowadays discourage cluster sizes for FAT and NTFS volumes that are less than 4KiB. (Since cluster sizes are powers of two, larger clusters sizes are always going to be multiples of 4KiB.)
In fact, as Rod Smith observes, Microsoft's disc partitioning utilities now default to aligning disc partitions to integer multiples of 1MiB. There's no really good reason for this. The days where it was worth observing that 1MiB was also 32 sectors × 64 heads are long since past. Indeed, for reasons already explained, that observation wasn't really worth much even in those days, since that was an entirely fake geometry that didn't match the actual physical disc geometry. The only reason for preferring 1MiB alignment to the smaller 4KiB alignment that the hardware actually needs is simply that it means that tools that display disc partition locations and lengths in terms of MiBs get to display whole numbers. Or, in other words, measuring partition placements and sizes in units of KiB is unnecessarily precise for users that are not themselves generally working in units smaller than GiBs when they are partitioning discs.
Unfortunately, by default Microsoft's fdisk and Disc Manager prior to 2008, and the current version of Linux's fdisk, produce partitions that aren't aligned to 4KiB boundaries. This is for the simple reason that the (faked) disc geometry that is used for most discs (certainly for those larger than 7.87GiB) employs 63 sectors per track. Aligning to a "track" boundary, as those old and daft utilities do, aligns to a multiple of 63 sectors. Starting the first primary partition at cylinder zero, head one, sector one — logical block number 63 of the disc —, as many disc partitioning utilities did, aligned that whole partition to an odd sector number.
So discs partitioned with such old disc partitioning utilities have to be adjusted. This adjustment involves moving (i.e. sliding) existing partitions up or down so that they start and end at 4KiB, or 1MiB, integer multiples. (If they were aligned to fake 63-sector "tracks", there's often enough wiggle-room between partitions, or at the start or the end of the disc, in the old PC/AT "MBR" partition table scheme to re-align to integer multiples of 4KiB.) This is a fairly time-consuming process, since it of course has to read and then write every sector in each partition on the disc that needs to be moved.