When your RAID controller (like the HP P420i) asks for sectors per track in 2023, you're encountering a fascinating relic of storage history. Despite modern drives using logical block addressing (LBA), some controller BIOS interfaces still maintain this legacy parameter. For 2TB SAS drives, both 32 and 63 are common choices, but here's what actually matters:

# Show actual drive geometry in Linux (2.8+ kernel)
hdparm -g /dev/sdX
# Modern output will show LBA, not CHS values

The number 63 comes from classic CHS (Cylinder-Head-Sector) geometry where:

• 512 bytes/sector × 63 sectors/track × 255 heads = 8.4GB limit (original ATA constraint)
• Modern controllers emulate this for backward compatibility

The P420i handles this differently than software RAID:

# Compare with software RAID (mdadm) which completely ignores CHS:
mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdX /dev/sdY

For your 2TB SAS drives on P420i:

• Use 63 sectors/track if creating bootable arrays (matches MBR expectations)
• 32 may work but could cause alignment issues with certain OS installers
• For data-only arrays, either value works as the controller translates to LBA

After array creation, check alignment:

# Check sector alignment (should show 0 for optimal performance)
cat /sys/block/md0/queue/optimal_io_size
cat /sys/block/md0/alignment_offset

Remember that modern filesystems like XFS or ZFS will handle sector alignment automatically when created on properly configured arrays.

When your P420i controller asks for sectors per track during SAS drive configuration, you're encountering a ghost of the old Cylinder-Head-Sector (CHS) addressing system. Modern drives use logical block addressing (LBA), but RAID controllers often maintain CHS parameters for backward compatibility. The values (typically 32 or 63) are largely vestigial on 2TB+ drives.

The default 32 sectors per track traces back to early ATA standards, while 63 originates from historical hard drive geometries:

// Classic CHS calculation example from legacy systems
unsigned int calculate_chs(unsigned int lba) {
    unsigned int sectors_per_track = 63;
    unsigned int heads = 16;
    return (lba / (sectors_per_track * heads));
}

While the parameter seems archaic, incorrect settings can still affect:

• Alignment with RAID stripe sizes
• Partition table generation
• Some legacy disk utilities' behavior

For your 2TB SAS drives on a P420i, either value will work, but 63 provides better alignment with common block sizes.

When configuring your RAID array:

# Example MegaCLI command for optimal alignment
./MegaCli -CfgLdAdd -rX [E:S] -szYYYYY -a0 -strpsz64 -Hsp -Direct -sectorspertrack63

Key considerations:

1. Match your controller's native block size (usually 64KB)
2. Ensure alignment with filesystem clusters
3. Verify performance with both settings using:

hdparm -tT /dev/sdX

With 2.8+ kernels, the parameter has minimal impact as the block layer abstracts physical geometry. You can verify settings with:

# Check detected geometry
fdisk -l /dev/sdX | grep "sectors/track"

# Modern alternative examining logical layout
blockdev --report /dev/sdX