I believe the term you're looking for is "magnetic domain", "a region within a magnetic material which has uniform magnetization" (wp). Hard drive designers are always trying to reduce the size of the magnetic domains.
But.
First, "channel codes" are used: The 0s and 1s recorded on the drive are not the same as the 0s and 1s you write and will eventually read. Sawdust is correct about how 1s and 0s are recorded, but there's more: The drive recovers clock pulses (so it can know where to expect a flux reversal, if there is one) from the flux polarity reversals, but cannot do so from stretches where there are no reversals.
This can be a problem. It's entirely plausible that someone might write an entire sector - 4096 bits with 512-byte sectors - of all 0s! Which would (if recorded simply) have no flux reversals. Due to irregularities in rotation speed, among other things, the drive would likely "lose its place" long before the end of that sector.
So the data to be written is actually expanded into somewhat more bits, using a channel code that ensures there will never be more than some number of non-flux-reversals written in a row.
I don't have a reference for the channel codes used in modern hard drives, but you can get a sense for how it works by looking up the "eight to fourteen modulation" ("EFM") that's used on CDs. Under EFM, each group of eight bits (which have 256 possible combinations of 0s and 1s) gets converted to a sequence of 14 bits (16384 combinations, but only 256 of them are valid codes). The sequences within each 14-bit code are chosen so that there are never more than a few - I think it's three - non-flux-reversals (0s) in a row. They're also chosen so as to reduce the bandwidth of the signal. Sounds bizarre, but it's true: By recording more bits you can get away with fewer flux transitions. For example, eight bits of all 1's would require eight flux reversals without a channel code, but instead can be recorded as 14 bits with far fewer than eight flux reversals.
Now, think about the very first bit written to a sector. Let's assume it's a 0. Where is it? Thanks to the channel code, the first bit actually written to the sector might well be a 1!
Incidentally, talking about CDs is not as off-point as it might seem. CDs use a similar scheme to that described by sawdust: The beginning or end of a "pit" marks a 1, a place where a pit could begin or end, but does not, is a 0. Just like flux reversals.
Then there's error correction. Error correction involves additional data stored with each sector. In the past the drive would read the primary data field + the ECC data of the sector, and if any errors were detected (for example, by reading one of the many "should not exist" channel codes), it would use the ECC data to correct the errors.
No more. Modern data densities are such that errors are more or less expected. So the ECC mechanisms were strengthened so that far more of the errors are correctable.
Yes, this does mean you have to record more bits, but it's a net win in terms of capacity.
The result, though, is that we can't really say that an individual bit, even a bit of a channel code, is recorded in a specific location, because the ECC data is as vital to recovering the bit as the channel code. And the way ECC works, the "influence" of each bit on the ECC data is spread over many, many bits of the ECC data. (This principle is called "diffusion.")
So, where's the bit? Well, it's sort of spread around. Change one bit in the input and there will be changes in the flux reversals in many places in the sector.
If that seems strange, wait until you learn about PRML, which stands for "probable response maximum likelihood": even the waveform recovered from the head, in which the drive looks for flux reversals, is interpreted statistically. But that doesn't have much to do with "where the bits are".
Some flash drives (and even external HDDs) have built-in software. These drives are made to look like 2 devices to the OS, the first is presented as a CD-ROM and the second is presented as a normal read/write mass storage device.
This is not partitioning as understood/done by the OS - it's done on a lower level - it's controlled by the microcontroller in the USB device.
Utilities from device manufacturers (often in Chinese) do exist to change this arrangement--and you have to use one compatible with the microcontroller--and they are difficult to find and use.
I'm betting this flash drive at one point was destined to have built in software on it, but the manufacturer changed their mind for whatever reason.
So the unallocated area probably was a fake "CD-ROM" area containing encryption or backup software from another SKU of drives this manufacturer (or possibly another manufacturer) offers.
The manufacturer probably had an oversupply of these particular devices or some other related economic condition, then ran a utility to reconfigure the flash arrangement and remove the "CD-ROM" partition, but didn't bother to wipe this section of flash before packaging.
You should run TestDisk on the unallocated partition and see what you can find!
Best Answer
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.