What's the point of hard drives reporting their physical sector size?

The 512-byte emulation is intended for compatibility with older systems. However, writes involving only part of a physical 4K sector can cause reduced performance because the sector needs to be read and modified before it can actually be written.

When a legacy operating system tries to write to an Advanced Format disk, performance issues can arise because the logical sectors written may not match up with the physical sectors.

  • When only part of a 4K physical sector is read, the data is simply read off the physical sector and there is no reduction in performance. However, when the system tries to write to part of a physical sector (e.g. an emulated 512-byte sector rather than the whole physical sector), the hard drive needs to read the whole physical sector, modify the changed portion in the hard drive's internal memory, and write it back to the platters. This is called read-modify-write (RMW), an operation which requires an extra rotation of the disk and therefore reduces performance. Seagate explains this as follows:

[...] the hard drive must first read the entire 4K sector containing the targeted location of the host write request, merge the existing data with the new data and then rewrite the entire 4K sector:

Read-modify-write cycle

In this instance, the hard drive must perform extra mechanical steps in the form of reading a 4K sector, modifying the contents and then writing the data. This process is called a read-modify-write cycle, which is undesirable because it has a negative impact on hard drive performance.

Disk partitions that are not aligned to a 4K boundary can cause degraded performance as well.

  • Traditionally, the first partition on a hard disk starts at sector 63. Windows XP and older operating systems partitioned disks in this manner. Newer versions of Windows will create partitions on a 1 MB boundary, ensuring proper alignment to the physical sectors. This is called Alignment 0.

    • This odd number is an artifact of cylinder-head-sector (CHS) addressing used in INT 13h, the legacy BIOS API used for disk access. On legacy systems and bootloaders that used the INT 13h API, all partitions must begin and end on cylinder boundaries. Even after logical block addressing (LBA) was introduced, fake CHS values (which did not correspond to the actual disk geometry) were used to maintain compatibility with the legacy API. Since CHS addressing originally supported a maximum of 63 sectors per cylinder, the first partition would begin on sector 63. Windows XP (before Service Pack 3) and earlier versions of Windows will not boot if the system volume isn't on a cylinder boundary.
  • Because LBA 63 is not a multiple of 8 (eight 512-byte legacy sectors fit into a 4K sector), an Advanced Format disk which is formatted in the old manner will have clusters (the smallest unit of filesystem data allocation, typically 4K in size) that are not aligned to the physical sectors on a 4K disk, a condition called Alignment 1. As a result, an I/O operation that otherwise involves 4K of data now spans two sectors leading to a read-modify-write operation that reduces performance.

While information about physical sector size is unnecessary if the OS always writes data on a 4K boundary, this information may still be needed by applications which perform low-level I/O.

  • When a drive reports that its physical sector size is 4K, the OS or application can tell that it is an Advanced Format drive and therefore must avoid performing I/O operations that do not span full physical sectors. A drive that reports 512-byte native sectors does not impose this restriction. While newer operating systems will usually try to read or write data in 4K units whenever possible (making this information irrelevant), applications which perform low-level I/O may need to know the physical sector size so that they can adjust accordingly and avoid misaligned or partial-sector writes that cause slow RMW cycles.

Your SSD provides the ability to change the reported physical sector size because it is necessary for compatibility with certain storage arrays.

  • Datacenters often have storage arrays consisting of legacy 512n drives. 4K drives, even those that emulate 512-byte sectors, may not be compatible with such arrays, so this feature is necessary to ensure compatibility. See this forum thread:

    We can't just stick a 4K drive in an array formatted with 512b disks. Many arrays (most notably ZFS based storage, which is increasingly popular as software defined storage makes waves) will not accept a replacement drive with a different physical sector format.

    Note that better performance will be attained on modern systems if the drive is configured to use 4K sectors.


What benefit does an OS gain by being aware of the physical sector size when, regardless, the OS has to talk to the drive in 512-byte sectors.

The logical size is a minimum size to transfer data. Since this is a block device, any data transfer between host computer and drive will be in multiples of this logical block size.

The physical size is an optimal size to transfer data, and reflects the size of the actual read and write operations at the controller/drive level.

When the host computer requests a read of a logical sector, the controller/drive will perform a read operation of the physical sector that contains the logical sector.
When the logical sector size is equal to the physical sector size, the operation is simple. When the logical sector size is less than the physical sector size, the logical sector has to be extracted from the physical sector by the controller for transfer to the host computer.

When the host computer requests a write of a logical sector, the size of the physical sector matters.
When the logical sector size is equal to the physical sector size, the write operation is simple, and can proceed directly. The condition of the previous contents of the sector will not affect the write operation.

When the logical sector size is less than the physical sector size, the controller must first perform a read operation of the physical sector that contains the logical sector.
If the read is successful, then the logical sector is inserted into the physical sector, and the physical sector is written in its entirely.
If the read is not successful (even after retries), the write operation cannot be completed.

If the OS performs the read and write operations with the physical sector size (by utilizing the multi-sector operations available in the ATAPI command set), the write operations will be performed more efficiently (and without an unnecessary chance of incompletion).

The LOGICAL sector size entirely defines how an OS can talk to a drive. No exceptions. What use is it knowing the physical sector size, when you're only allowed to communicate in logical sector size?

Your contention of "no exceptions" is incorrect.
The ATAPI command set, which was introduced with the IDE HDD, has always had the capability to perform read and write operations with a sector count parameter. This is merely an extension of existing disk and floppy controller interfaces that were also capable of multi-sector read/write operations (so long as the sectors were on the same track).


If the OS knows the underlying physical sector size, it can optimize its queries to require as few physical operations as possible. Particularly with SSDs, the physical operation limit (4KB IOPS limit) is often the ultimate limit of device speed, so being able to make best use of this capacity is important.