How do heads find the data stored on a hard disk drive?
By reading (and comparing) the address information of each sector as it rotates under the head.
The details (as performed by the disk controller):
The disk controller positions the R/W head assembly from its current position to the requested cylinder.
(The time to perform this operation is called the seek time.)
The disk controller selects the requested read/write head.
(The time to perform this operation is called the head settle & select time.)
The disk controller waits for the requested sector to rotate into position.
3a. As each sector is encountered (by an interrupt triggered by finding an Address Mark on the track), the Identification record of the sector is read.
3b. If the ID record does not match the requested cylinder or head, then a seek or controller error occurred, and an error procedure needs to be performed.
3c. If the ID record does not match the requested sector, then continue waiting for the next sector (i.e. repeat 3a).
3d. Otherwise the requested sector has been found, since the ID record does match the requested cylinder, head and sector (or logical sector number or LBA).
(The time to perform this operation is called the rotational latency.)
Note: If the Index mark is encountered twice (i.e. more than one full rotation), then the entire track has been scanned, and the requested sector has not been found. An error procedure needs to be performed.
I heard that to read or write data on a hard disk drive, we need the cylinder id and the sector id.
You omitted the (read/write) head number.
First move the hdd's r/w heads to the cylinder specified by the cylinder id, and then to the sector specified by the sector id. Is it correct?
Not quite. The first part is accurate, but not the latter.
Do we need the platter id, ...
Not really.
... and which of the two surfaces of the platter?
There's one read/write head per surface.
So specifying the head number selects a surface of a platter.
Or equivalently, the track id (since we have the cylinder id)?
At the disk controller level, a "track id" is typically not used. The cylinder number and head number are more useful.
Since the original IBM PC BIOS interfaced directly with the disk controller (based on a Western Digital chip), the BIOS had to use this cylinder, head, sector (aka CHS) addressing. But as the disk controller was relocated from the ISA bus to the drive enclosure (IDE style), the ATAPI command set made CHS addressing essentially obsolete in favor of logical sector addressing.
Also see When a disk read or disk write occurs where does the data go?
My previous understanding is that all information was stored in a binary form (0s and 1s) on hard drives, and in blocks of 8-bits, in modern computer hard drives. And that hexadecimal is utilized to facilitate the display of information, so humans aren't required to read through long blocks of bits.
That's 100% correct. Hexadecimal is merely a representation of data; there's nothing special about the nature of hexadecimal compared to other formats. It doesn't enable data compression or anything like that.
I think what your friend was referring to is the difference between representing numbers as character strings versus representing numbers as numbers.
For unsigned integers -- which is a representation of numbers in bits (zeroes and ones) from 0 to a certain, fixed, maximum number -- the maximum number that can be represented by N bits is 2^N, minus 1, assuming you start with 0.
So, if you have 8 bits (a.k.a. 1 byte), you can represent every number from 0 to 255 without losing information; you can manipulate these eight bits between 0 and 1 to unambiguously represent every number from 0 to 255, inclusive. Or from 1 to 256, if you prefer. It doesn't matter. Computers tend to represent them starting from 0, though.
If you have 16 bits (2 bytes), you can represent every number from 0 to 65535 (that's 2^16 - 1). 32 bits, every number from 0 to 4294967295. 64 bits, every number from 0 to a number that's 1.8 with nineteen zeroes.
You might know from algebra that 2^N is an exponential function. That means that, even though 64 bits is only eight times more bits than 8 bits, it can store way, way, way more data in that 8-times-more-bits than the number 255*8 (which is only 2040!). 2040 is a very small number compared to approximately 180000000000000000000. And 64 bits can store EVERY number from 0 all the way up to that maximum.
One interesting implication of integers stored in this way is that the programmer must decide in advance how big the storage needs to be, which in turn, determines the maximum number that can be represented by a given integer. If you try to store a number bigger than the storage can handle, you get something called overflow. This happens, for example, if you have an 8-bit integer, that's set to 255, and you ask the computer to add 1 to it. Well, you can't represent 256 within an integer whose range is 0 to 255! What usually happens is it "wraps around" back to the start, and goes back to 0.
There are programs that perform math in a mode called "arbitrary-precision" that automatically resize their storage to grow bigger and bigger depending on how big the numbers being handled are; for example, if you multiplied 255 by 100000, the answer would have to grow beyond 8 bits, and beyond 16 bits, but would fit within a 32-bit integer. If you input a number or performed a math operation that produced a number larger than the maximum for a 64-bit integer, it would have to allocate even more space for it.
HOWEVER -- if you represent numbers as a character string, then each number will take up as much space as a letter in written prose. "ASDF" and "1234" take up exactly the same space. "OneTwoThreeFourFive" (19 characters) takes up the same space as "1234567890123456789". The amount of space required grows linearly with the number of numbers (or letters, or characters, generically) you have. That's because each character can represent any of a myriad of characters within the character set, and numbers are just characters in a character set. A specific sequence of zeroes and ones will produce the number "3", a different sequence will produce "4", etc.
Typically characters are stored taking up either 8 or 16 bits, but some character encodings either take up a variable number of bits depending on the character (like UTF-8), or always take up a larger number of bits (like UCS-32).
If each character takes 8 bits, "OneTwoThreeFourFive" and "1234567890123456789" both take up 152 bits. But "1234567890123456789" can fit within a 64-bit unsigned integer, which... only consumes 64 bits. That's a savings of 88 bits! And we didn't even use any "data compression" tricks like Zip, 7-Zip, RAR, etc.
Best Answer
"It depends." All other things being equal, platter density does directly correlate to an increased sequential transfer rate.
However, you need to know what the platter density is. If that 400 GB drive has 2 x 200 GB platters and the 80 GB drive uses 1 short stroked 200 GB platter, then the 80 GB drive would be faster overall (because the average seek time will be smaller).
The extra drive space may end up being useful in some other way over the life of the system though. Unless you're looking at buying thousands of systems were $13/ea is a budget breaker, I'd opt for the larger hard drive immediately. Otherwise if you end up wanting or needing a larger drive, you're looking at not just the expenses of the drives themselves, but of your time spent swapping the drives and imaging the contents.
Personally, I wouldn't install such a small drive in a new system unless there were other considerations coming into play. (e.g. It's an SSD, budget sensitivity, etc.)