[hsmultimedia]

I just bought a new 320 GB hard disk. But apparently some 22 GB of space have vanished -- "Get Info" says the disk holds about 298 GB of space. 22 gigs -- that*s 8,000 times the space on the hard disk of my first Mac. Where does it all go? /forums/ubbthreads/images/graemlins/blush.gif

[griffman]

Some is lost to formatting and overhead, but if you want to see where all the actually used space went, get WhatSize and run it.
-rob.

[mdawson]

Disks and hard drives have long been sold based on their unformatted capacity, not what you get once the drive is formated and ready to use. Add to that the fact that hard drive manufacturers long since abandoned indicating capacities based on the base 2 computer science standardwhich by the way computer operating systems typically still use when reporting used and free space on disksand the discrepancy grows. Here is some info on drive capacity that I posted on another forum long ago that should sum things up for you:

Quote:

---

Lets look at the simple (old) floppy disk model. A single-sided, single density (SSSD) disk had a 216K disk size but were advertised as 180K disks. This is based on the fact that these disks were formatted as follows:

[*]256 bytes/sector
[*]18 sectors/track
[*]40 (of 48) tracks/side
[/list]
Typically at least one track was reserved for the directory. This effectively made the disks capacity 175.5K or 97.5% of the quoted size. From what I remember from engineering courses using statistical data in terms of production a 5% discrepancy was considered good and a 2.5% tolerance was considered high. The SSSD disk falls into the latter category in terms of what the user had available for data storage. If we were to go by the disks true rating (48 tracks, 216K) the loss is 18.75%, but few floppy disk users would bother to calculate the loss they accrued because drive manufacturers only made 40-track disk drives.
Now another issue is that the user still does not get 175.5K. This is because the operating system or in those days, disk operating system (DOS)this in not a Microsoft reference as all disk operating systems were known as DOSesneeds to be able to reference blocks on the disk. Some more sophisticated DOSes were able to finagle this on a sector level, but most, particularly those on more consumer-oriented personal computers, had minimum block sizes of anywhere from two to 9 sectors. The reason for this was the directory structurea contemporary example is the Macs HFS disk structure has a 4K minimum block or the equivalent of 8 contemporary (512-byte) sectors.

If a DOS had a minimum block size of two sectors and you saved a file that was 7389 bytes (7.22K) the system would use 16 sectors (8K). If the modulus of file size/minimum block size returns even 1 byte the bulk of an entire data block goes to waste; this would be the equivalent of a 99.80% capacity loss in the two sector data block or a 99.97% loss in an HFS data block. Even if the DOS used individual sectors 221 bytes would be wasted. This adds up to quite a bit of unusable bytes as more files are saved. This is why you may get a disk full error on a 1.4MB floppy with what appears to be 100K remaining when you try to save a 99K file. The space remaining is often based on calculations done on actual file sizes not minimum data blocks.
Given the 8.3 filename convention typically used in personal computers of the 1970s and 1980s for each file the directory would need at least 16 bytes:


[*]filename, 8 bytes
[*]extension, 3 bytes
[*]size, 2 bytes (assuming a 64K max. file size which was huge back then)
[*]date created/modified, 2 bytes for date code
[*]pointer to first data block of actual file, 1 byte
[/list]
This of course is a simplified model. The directory would also contain a disk map, obviously, and would have to contain the map and visible directory data above in just 4.5K without knowing in advance how many files will be on a disk; remember that a minimum of 16 bytes is needed just for the directory data that is shown when a DIR (or equivalent) command is entered and then there are the several bytes that are required to map the files data on the disk.
As density increased so did the need for the directorys space. Lets assume a linear model where one track is needed per 40 tracks to store directory information a 2.5% loss. So a SSDD (360K, 80 tracks, 1 side, 2 directory tracks used) or DSSD (360K, 40 tracks, 2 sides, 1 directory track used per side) disk would only have a capacity 351K and a DSDD disk (720K, 80 tracks, 2 sides, 2 directory tracks per side) would have a capacity of 702K.
Now lets look at contemporary hard disk based on the same model. Hard drive manufacturers often quote disk sizes based on the decimal metric system (1K = 1000) instead of the base-2 numeric model (1K = 1024) that has been used in terms of computer memory and storage since the beginning. Thus a hard drive quoted to have a size of 30GB has 30,000,000,000 bytes available as opposed to the expected 32,212,254,720 bytes. At a 2.5% loss a 30GB drive would have 29,250,000,000 bytes or 27.24GB in standard computer nomenclature. By the same token a 120GB drive would have 117,000,000,000 bytes or approximately 109GB.
Now while that may seem like quite a bit you have to consider that this analysis has not taken into consideration that modern operating systems place system info on the disk, filenames can be up to 32x longer, sector size has doubled to 512 bytes, maximum file sizes have increased geometrically, most drives have the ability to map out bad sectors, etc. Directories are far more complex now and disks have more blocks per capita available to them then they did back in the days of SSSD 5 1/4-inch floppies.


---

[MacCheetah3]

Hi
Put simply...Formatting takes away ~7% of the advertised capacity.

[drmbb]

As stated, if you just do the math, 320GB (base 10 math) equals almost exactly 298.02322...GB of binary storage.
(320,000,000,000)/2^30 = 298.02
GB - market-speak = 10^9
GB - real world, binary computing = 2^30

[mdawson]

Or even simpler, 2^30 may be a bit over peoples headsthey will not see the pattern that leads to that number, here is the HDD manufacturers math:

[*]1 KB = 1000 bytes
[*]1 MB = 1000 KB = 1,000,000 (1000^2) bytes
[*]1 GB = 1000 MB = 1,000,000,000 (1000^3) bytes
[/list]While this numbering system is correct from a mathematical standpoint based on the base10 system we mere mortals use everyday, it is completely wrong in computer nomenclature. (And I know a certain someone will probably chime in about the kibi, mibi, etc. crap that was created to cover for the discrepancy, but computer scientists have been using the Greek ISV prefixes for nearly four decades and that is not about to change.) So, in computer science parlance we have:

[*]1 KB = 2e10 bytes = 1024 bytes
[*]1 MB = 1024 KB = 2e20 bytes = 1,048,576 (1024^2) bytes
[*]1 GB = 1024 MB = 2e30 bytes = 1,073,741,824 (1024^3) bytes (see the pattern /forums/ubbthreads/images/graemlins/smile.gif)
[/list]The base2 system is what OS X and Windows use when they report memory usage and drive capacities, so a computer with 512 MB of RAM actually has 536,870,912 bytes and not 512,000,000 bytes as one would think.

[hsmultimedia]

Wow! I think this more than answers my question -- it almost destroys the question! Hum... I'd hoped for something along the line: You're being cheated! Let's revolt! But I guess I'll just have to be happy that bytes are getting cheaper every day. Anyways, thanks for your explanations! /forums/ubbthreads/images/graemlins/smirk.gif