Sector (Disk Sector)

The sector concept dates to the earliest hard drives. The IBM RAMAC 305 in 1956 organized its 5 MB of storage into 100-character sectors on rotating platters. The IBM 3340 in 1973 standardized on 512-byte sectors, a size that persisted for the next 37 years. From the late 1950s through 2010, virtually every hard drive in production used 512-byte sectors, and the entire software ecosystem (BIOS, operating systems, partition tables, file systems, imaging tools, RAID controllers) was built around that assumption.¹

The defining property of a sector is atomicity. The disk reads or writes an entire sector in a single operation; nothing smaller is possible at the hardware level. If software wants to change a single byte in the middle of a sector, the drive must read the whole sector into its internal buffer, modify the byte, and write the entire sector back. The OS handles this abstraction transparently, but the underlying hardware constraint shapes everything above it.

The internal sector layout

A disk sector is not just the user data. Each sector on a hard drive includes overhead fields that the drive uses for its own purposes:²

• Gap: a small unused region between sectors that gives the drive head time to settle before reading or writing.
• Sync mark: a known bit pattern at the start of the sector that helps the drive lock onto the data clock.
• Address mark: identifies which sector this is on the disk, used for verification.
• Data: the actual user data (512 bytes on legacy drives, 4096 bytes on Advanced Format drives).
• ECC (Error Correction Code): 50 bytes for legacy 512-byte sectors, ~100 bytes for 4 KB sectors. Used to detect and correct read errors caused by media defects.

The user-visible sector size (512 bytes or 4 KB) refers only to the data field. The drive’s internal physical sector is larger because it includes all the overhead. This is why the storage capacity reported by a drive is the sum of the data fields, not the total magnetic surface area.

Logical Block Addressing (LBA)

Modern drives present sectors as a flat sequence of Logical Block Addresses, numbered from 0 upward. LBA 0 is the first sector, LBA 1 the second, and so on. The drive firmware translates LBAs into physical positions on the platter (or flash chips), abstracting away the physical layout. Software just says “give me LBA 12345” and gets back a sector’s worth of data; it doesn’t know or care which platter, head, track, and sector that LBA actually lives on.

Before LBA, drives used Cylinder-Head-Sector (CHS) addressing that exposed the physical geometry directly. CHS was eliminated as the primary addressing scheme in the late 1990s because the physical geometry of modern drives no longer matches the simple cylinder-head-sector model: zoned bit recording, head/sector reallocation, and SSDs all break the assumption that physical position can be inferred from CHS coordinates. Modern partition tables and file systems use 32-bit or 64-bit LBA values exclusively.

Why 512 bytes was the historical standard

The 512-byte size was a 1970s engineering compromise. Smaller sectors meant more overhead (more sync marks, address marks, and ECC fields per unit of capacity), reducing usable storage. Larger sectors meant more wasted space when storing small files and made bad sector remapping more expensive. 512 bytes hit the sweet spot for the drive sizes and workloads of the era: large enough to amortize overhead, small enough to be efficient for typical small-file workloads.³

The standard outlived its usefulness as drive capacities grew. By 2005, drives were 100,000 times larger than the original 512-byte sectors were designed for; the per-sector overhead became a real fraction of capacity, and the 50-byte ECC field couldn’t reliably correct errors in increasingly densely-packed magnetic media. The industry’s solution was Advanced Format.

Modern drives have two sector sizes: the actual physical sector size on disk, and the logical sector size reported to the operating system. Understanding both is essential for partitioning, formatting, and recovery.⁴

Physical sector

The size of the actual on-disk structure: data field plus all overhead (gap, sync mark, address mark, ECC). This is the unit of atomic write at the hardware level. A modern HDD writes a 4 KB physical sector as one operation; it cannot write less than that.

Logical sector

The unit reported to the operating system, used in LBA addressing. The OS sees the disk as a sequence of logical sectors. On a drive where physical and logical sector size match, this is straightforward. On 512e drives (see below), logical sectors are smaller than physical sectors, and the drive firmware translates between them.

512n: native 512-byte sectors

The legacy format. Both physical and logical sectors are 512 bytes. Used by every consumer hard drive made before 2011 and most enterprise drives before 2014. Found today only on legacy systems, low-capacity drives, and some specialized industrial storage. Most users will not encounter 512n drives in 2026.

512e: 4 KB physical, 512-byte logical (the modern default)

Both physical sectors are 4096 bytes (Advanced Format), but the drive firmware presents 512-byte logical sectors to the host for compatibility with legacy software. Most consumer HDDs sold since 2011 are 512e: the disk has Advanced Format internally but reports 512-byte sectors to the OS. Windows 7 and later support 512e natively; older Windows versions mostly work but with alignment issues that cause performance problems.⁵

4Kn: 4 KB physical, 4 KB logical (true Advanced Format)

Both physical and logical sectors are 4096 bytes. The drive reports 4 KB sectors directly with no emulation. Better performance for large I/O, no alignment penalty, but requires modern operating systems (Windows 8+, Linux 2.6.31+, macOS Lion+) and modern firmware. Most enterprise drives shipped since ~2014 are 4Kn; most consumer drives still default to 512e for backward compatibility.

The read-modify-write penalty on 512e

The downside of 512e: when the OS writes a single 512-byte logical sector, the drive must read the entire 4 KB physical sector into cache, modify the affected 512 bytes, and write the whole sector back. This roughly doubles the I/O work for misaligned writes. Modern operating systems mostly avoid this by aligning writes to 4 KB boundaries, but legacy applications and misaligned partitions can hit the penalty repeatedly.⁶

To check sector sizes on Linux:

This output shows a 12 TB Seagate enterprise drive in 512e mode: logical 512, physical 4096. Linux reports the optimal I/O size as 4 KB, signaling to applications that they should align their I/O to 4 KB boundaries even though the logical sector is 512 bytes.

The transition from 512-byte to 4 KB sectors was driven by storage industry needs that became urgent around 2010. Increased areal density (bits per square inch) made the 50-byte ECC field of 512-byte sectors inadequate for reliable error correction. The trade-off of larger sectors with stronger ECC vs smaller sectors with more granular access tipped clearly toward larger sectors.⁷

Property	512-byte sector (legacy)	4 KB sector (Advanced Format)
Years in use	1973-2010 (and ongoing in legacy)	2010-present
Sector size	512 bytes data	4096 bytes data (8x larger)
ECC field size	~50 bytes	~100 bytes (2x larger)
ECC strength	Adequate for ~2008-era density	Adequate for modern high-density media
Format efficiency	Lower (more overhead per byte)	Higher (fewer gaps, syncs, address marks)
Storage capacity gain	Baseline	~7-11% more usable capacity
Read-modify-write on small I/O	None (sectors are 512 bytes)	Yes (penalty on writes < 4 KB)
OS support required	Universal	Windows 7+ (512e) / Win 8+ (4Kn), Linux 2.6.31+
Required for disks > 2 TB on MBR	No (limits to 2 TB)	Yes (16 TB max with 4 KB sectors)

Identifying which format you have

Most consumer HDDs purchased since 2011 are 512e. Most enterprise HDDs purchased since 2014 are 4Kn. Most consumer SSDs and NVMe drives are 512e for compatibility, though some newer high-capacity drives are 4Kn. To check:

• Linux: sudo fdisk -l /dev/sdX shows logical and physical sector size. Or sudo hdparm -I /dev/sdX | grep Sector.
• Windows: fsutil fsinfo ntfsinfo C: shows “Bytes Per Sector” (logical) and “Bytes Per Physical Sector.”
• macOS: diskutil info disk0 | grep "Block Size" shows Device Block Size (physical) and File System Block Size (logical/cluster).

SSDs and the sector concept

SSDs and NVMe drives don’t have physical sectors in the spinning-rust sense. Their internal storage is organized into pages (typically 4-16 KB) grouped into blocks (typically 128-256 pages, or 512 KB to 4 MB). The flash translation layer (FTL) inside the drive presents logical sectors (usually 512 bytes or 4 KB) on top of this page/block structure. The “sector” the OS sees on an SSD is purely a logical abstraction; there’s no direct physical correspondence.⁸

This matters for recovery: SSD wear leveling, TRIM (see the upcoming TRIM Command entry), and garbage collection move data between physical pages and blocks behind the scenes, so a “sector” at LBA 12345 today might be on a completely different physical page tomorrow. Sector-level recovery on SSDs has fundamentally different dynamics from HDDs.

Sectors are the foundation everything else builds on. Every other entry in the storage stack glossary is shaped by the underlying sector size, sometimes in subtle ways.⁹

Partition tables

The MBR is exactly one 512-byte sector at LBA 0. The GPT primary header is at LBA 1, with the partition entry array spanning LBAs 2-33. Both partition table formats are defined in terms of LBA positions, and both work on 512-byte and 4 KB sector drives, though the actual byte offset of the GPT partition entries differs (sectors 2-33 means bytes 1024-17407 on a 512-byte drive but bytes 8192-139263 on a 4Kn drive).

File system clusters

File systems group sectors into clusters (NTFS, exFAT, FAT32 terminology) or blocks (ext4, APFS terminology) for allocation efficiency. A cluster is always a power-of-two multiple of the sector size. Common values:

• NTFS on 512-byte-sector drives: typically 4 KB cluster (8 sectors), can range from 512 bytes to 64 KB depending on volume size and format options.
• NTFS on 4Kn drives: typically 4 KB cluster (1 sector); the file system’s cluster equals the disk’s physical sector.
• exFAT: default 32 KB or 128 KB cluster on large volumes. See the exFAT entry.
• FAT32: 4 KB to 32 KB cluster depending on volume size. See the FAT32 entry.
• ext4: 4 KB block by default (1 sector on 4 KB drives, 8 sectors on 512-byte drives). See the ext4 entry.
• APFS: 4 KB block. See the APFS entry.

Partition alignment

For maximum performance, partitions should start at boundaries that are multiples of the underlying physical sector size. On a 4 KB physical sector drive (whether 512e or 4Kn), partitions should start at LBA values that are multiples of 8 (when using 512-byte logical sectors) or multiples of 1 (when using 4 KB logical sectors). Modern partitioning tools default to starting partitions at LBA 2048, a 1 MB offset, which is aligned to anything up to 1 MB physical sectors. Misalignment is mostly a legacy issue from XP-era systems migrated to modern Advanced Format drives.

Disk imaging

Tools like dd, ddrescue, and HDD Raw Copy Tool read disks sector by sector. The block size used by the imaging tool should match or be a multiple of the source’s physical sector size. Imaging a 4Kn drive with dd bs=512 works but is suboptimal because every read becomes a partial physical sector access; dd bs=4M reads thousands of physical sectors per operation, much faster. The ddrescue tool’s default --cluster-size=128 (64 KB on 512-byte sectors) is a reasonable choice for most scenarios.

Sector-level problems cause distinctive failure patterns that can be diagnosed at the SMART or sector-imaging level. Recognizing them early is the difference between a routine recovery and an unrecoverable disk.¹⁰

• Bad sectors (read errors). Physical sectors that fail their ECC check and can’t return reliable data. Symptoms: dmesg on Linux shows “I/O error” messages; Windows event log shows disk error events; SMART attribute “Reallocated Sectors Count” or “Pending Sector Count” rises. The data in those specific sectors is gone, but everything else is salvageable. See the upcoming Bad Sectors entry for detailed coverage.
• Sector remapping (silent recovery). Modern drives detect failing sectors and reassign them to spare sectors from the drive’s spare pool (G-list / Grown defect list). The OS doesn’t see the failure unless many sectors fail at once or the spare pool is exhausted. SMART attributes track this; rising remap counts predict eventual drive failure.
• Misaligned partitions on 512e drives. Partitions start at LBA values that aren’t multiples of 8, forcing read-modify-write penalties on every write. Performance is dramatically slower than it should be. parted /dev/sdX align-check optimal 1 on Linux verifies partition 1 is properly aligned.
• Sector size mismatch when cloning. Imaging a 512e drive’s sector-by-sector image to a 4Kn drive (or vice versa) produces a destination where partition tables and file systems are off by a factor of 8 from where they should be. The destination disk usually mounts as RAW or shows wildly wrong sizes. Recovery requires re-imaging at the correct sector size or reconstructing the file system on the destination.
• SSD page-level corruption. SSDs occasionally corrupt entire pages (4-16 KB) when their flash cells fail. Unlike HDDs where corruption is usually localized to a single 512-byte sector, SSD corruption can take out an entire 4-16 KB page atomically. The drive’s internal redundancy usually catches this, but rare bugs in the FTL or wear leveling can let corruption propagate.
• Boot sector damage. The very first sector of a partition (the Volume Boot Record on Windows partitions, the file system superblock on Linux ones) holds critical metadata. Bad sectors specifically at this location render the partition unmountable even if everything else is intact. NTFS, FAT32, and most file systems keep backup copies of the boot sector elsewhere in the partition specifically for this scenario.
• Last-sector damage on GPT disks. The GPT backup is at the last LBA of the disk. Bad sectors specifically at the end of the disk can wipe out the backup, weakening GPT’s redundancy. See the GPT entry for the recovery process.
• Slow access on specific files. Often bad sectors being retried by the kernel’s I/O layer. Read errors are usually retried 3-5 times before the kernel reports failure; if the retries occasionally succeed, files appear to work but very slowly. dmesg | grep -i error reveals the underlying issue.

Warning signs of sector-level problems

Drive firmware reports problems through SMART, but the OS shows symptoms first. Watch for these:

• Slow boot or slow file access for specific files. Read retries on bad sectors.
• “I/O error” or “Input/Output error” messages in dmesg on Linux or in Windows Event Viewer.
• SMART Reallocated Sectors Count rising over time. Use smartctl -a /dev/sdX on Linux/macOS or CrystalDiskInfo on Windows to monitor.
• SMART Pending Sector Count non-zero. Sectors awaiting reallocation. These are the bad sectors that haven’t been remapped yet.
• SMART Uncorrectable Sector Count rising. Sectors the drive couldn’t recover even with ECC. Lost data.
• Files reporting wrong sizes or empty when they should have content. Possible sector-level corruption in file system metadata.
• System hang during disk-intensive operations. Multiple bad sectors causing kernel I/O stalls.
• Different sector counts reported between BIOS and OS. Indicates drive firmware is in trouble, possibly a sign of imminent failure.