Exercise 1: Why HFS+ Needed 64-bit Inodes — Possible Solution
====================================================================

THE SPECIFIC LIMITATION FIXED
------------------------------
Per this chapter, HFS+ used 32-bit inode numbering, which put a hard, practical ceiling on how many files a volume could ever hold - once every possible 32-bit inode number had been assigned, no new files could be created on that volume, regardless of how much physical free space remained. APFS's 64-bit inode numbers push that ceiling astronomically higher, removing it as a realistic concern for any modern use.

WHY THE LIMITATION EXISTED IN THE FIRST PLACE
------------------------------
HFS+'s design traces back to extending the original 1985 HFS in 1998 - an era when the number of files a typical volume would ever hold was nowhere near large enough for a 32-bit limit to matter in practice. The design simply was never revisited or fundamentally redesigned as storage capacities and typical file counts grew over the following two decades, so a limit that was effectively unreachable in 1998 became a real, occasionally-hit ceiling by the 2010s.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly identifies the 32-bit inode ceiling as a hard limit on total file count rather than a performance issue, and explains that the limitation existed simply because HFS+'s underlying design predates the file counts that would eventually make it a practical problem, rather than being an intentional restriction.