Hard drives are getting bigger and bigger, a trend that leads to some technical challenges hard to overcome without user-noticable changes. The increase in hard disk size means that the areal density (the number of bits stored per square inch on the drive) also increases heavily, which is a good thing at first glance: The higher the areal density the faster the same amount of data can be read and written. Thus the drives not only get larger, they also get faster.

Larger, Faster And Less Reliable?

This comes at a cost, however. While the areal density increases, the signal-to-noise ratio of the data communication between disk head and platter decreases. In other words, the probability of defects that have to be corrected goes up. This can only be overcome by setting aside more space on the drive for error correction.

A hard drive is physically divided into sectors, the smallest unit a drive can modify and transfer from and to the computer at a time. These sectors have traditionally been 512 bytes in size, which was a perfectly fine choice thirty years ago, a time when hard drivers were five, ten or twenty MB in size.

Physically, on the disk platter, a sector is not 512 bytes, but actually bigger, because some administrative overhead is required (for example to mark the beginning and the end of a sector) and because of error correction. Now, if the signal-to-noise-ratio gets worse, more space is taken up by this administrative overhead: More error correction data is required.

For a drive with an areal density of 215 kbpi (kilo bits per inch) 24 bytes must be set aside for error correction -- per sector. That yields a format efficiency of 96% (the ratio of user data bytes on a disk versus the total number of bytes, not counting other administrative overhead). Now if areal density is increased to 750 kpbi the error correction requirements increase to 40 bytes per sector -- thus the format efficiency drops to 92%. Even higher densities require even more error correction data. It's obvious this is not optimal.

Larger Sectors Are More Efficient

Hard drive manufacturers have been aware of this problem for a long time. At the end of the 1990's they began to prepare what they see as the best solution to it: A move away from 512 byte sectors to larger ones. They eventually settled for a sector size of 4096 bytes, presumably because this value coincides with block sizes in many file systems and with the x86 memory page size. A 4096 byte sector requires 100 bytes of error correction data, yielding a format efficiency of 98% at 750 kbpi. Note how the sector is now eight times larger but the error correction data has increased only two and a half times in size: The benefits are obvious.

The first hard drives with 4096 byte sectors are being sold by Western Digital since the end of last year. By the first quarter of 2011, all drives sold by any manufacturer are planned to have the larger sector size.

The question is, how does this change affect users in a noticable way?

Unfortunately, many parts of the software stack on any OS simpy assumed a 512 byte sector size because the value has not changed in nearly thirty years. The Linux kernel did, many partition tools still do, and so did libparted, the library at the core of KDE Partition Manager. Hard drive manufacturers know this and thus have come up with a plan to make the transition easier: The drives use the new sector size of 4096 bytes internally ("physical sector size"), but still claim to use the traditional sector size of 512 byte ("logical sector size") if queried by the OS (at a later date, the logical size could be set to 4096 too, once all software has been checked to correctly work with the new sector size). And all is supposedly well.

Even More Historical Baggage

In theory. In practice we're just shifting around the problem a little because there is yet another traditional custom from thirty years ago biting us: Partition alignment on disk.

In the early days of personal computing, hard drives were physically divided not only into sectors, but also into tracks (one circle on one platter) and cylinders (one circle on all platters the disk has). Microsoft made it mandatory that partitions start and end on a drive only at cylinder boundaries.

No rule without exception, of course: The first partition on a drive (that would have started at a cylinder if it started at sector 0, which it cannot, because that's where the master boot record has to be) had to begin at sector 63 (which historically is the size of one track). Microsoft's Windows XP still uses this scheme, but can read and deal with partition tables that are laid out differently. Many Linux partitioning tools just adopted this scheme for maximum compatibility with MS-DOS/Windows based tools -- and still use it today.

Larger And Slower?

So, where does partition alignment come into play here and how does it hurt us?

Neither 63 nor the typical cylinder size used on today's hard drive (16065 sectors per cylinder) is evenly divisable by the ratio of new to old sector size (4096 / 512 = 8). This means that a partition starting at sector 63 cannot possibly start at the beginning of a physical sector of 4096 bytes: It's misaligned and starts in the middle of a phyical sector instead. For any 4096-byte-sized read-modify-write operation (remember that many file systems use 4096-byte-sized blocks) on this disk, two reads and two writes are necessary, which is not mechanically or electronically harmful but greatly hurts performance and is thus highly undesirable.

So the partition alignment scheme once mandated by Microsoft (partitions must begin at a cylinder boundary with the exception of the first which must begin at sector 63) now badly hurts consumers. Microsoft themselves abandoned this scheme with the introduction of Windows Vista: Vista and Windows 7 align partitions at MiB boundaries, that is, a partition starts at a sector number evenly divisable by 2048 logical sectors of 512 bytes.

Maximum Flexibility With KDE Partition Manager 1.1

KDE Partition Manager 1.0, like many partitioning tools in use today, still uses the traditional scheme for best compatibility with older MS-DOS based disk manipulation software. It will insist on aligning any partition it moves or resizes to a cylinder boundary. This has lead to some confusion among users already when the application moves a partition by a few sectors when making it larger or smaller.

Starting with version 1.1, the scheme used is configurable:

Either the old, MS-DOS and Windows-XP-compatible scheme or the new one can be globally set as a default. Also, for the latter, the sector alignment is configurable: It is not fixed to the default value of 2048 sectors.

In addition to that, when scanning each disk KDE Partition Manager 1.1 heuristically detects the partition alignment scheme used and uses the result for all size-related operations on this disk. The user can override the application's decision of which scheme to use on a disk by disk basis -- and that's what the mysterious radio buttons are for that were visible in the device property sceenshot shown yesterday:

For this disk sector alignment is being used (which is a wise choice, because it's one of the disks available already with 4096-byte-sized physical sectors).

Further reading:

• Western Digital’s Advanced Format: The 4K Sector Transition Begins
• Thread about 4096 bytes sized sector on the util-linux-ng mailing list
• Vista's New Partitioning Rules
• bigsector.org, web site of the hard drive manufacturer's association with details on the transition to 4KiB sectors

This concludes part three in a sequence of entries presenting some of the new features of the soon-to-be-finished KDE Partition Manager 1.1. Part one was about Mount Management, part two dealt with SMART Status Reports.