Hi all,

This is something I've often wondered about but never tried to find out
- why is it that when you buy a 400GB drive, hook it up to your
motherboard, you only get say 370GB? This is before it's been formatted
or anything.

I don't normally mind/notice the loss, but I've just built a RAID array,
and it was a bit of a shock that all I ended up with was 1.8TB instead
of 2.0TB.


TIA

--
Grunff

Capacity is the amount of data that the drive can store,
after formatting. Most disc drive companies, including Seagate,
calculate disc capacity based on the assumption that
1 megabyte = 1000 kilobytes and 1 gigabyte=1000 megabytes.

According to other sources:
1 megabyte = 1024 kilobytes and 1 gigabyte = 1024 megabytes.

Hence the difference.

Peter wrote:


But that doesn't quite account for the discrepancy. For example, my
drives are these:

<http://uk.insight.com/apps/productpresentation/index.php?product_id=HTGA03UOS>

They are quoted as 400GB drives, and yet my system sees them as 372GB
drives. The 1000/1024 difference isn't big enough - 372 * 1.024 = 381GB.


Any other explanations?

--
Grunff

Peter <peterfoxghost@yahoo.ca> wrote in message
news:auRbe.7627$BW6.776133@news20.bellglobal.com.. .

It isnt an assumption, thats the standard SI unit.

And all hard drive manufacturers state the drive size that way.

Who get it wrong. There is nothing intrinsically binary about
hard drive capacity. Thats only seen with ram and rom.

Indeed.

Grunff <grunff@ixxa.com> wrote in message
news:1114636289.17707.0@nnrp-t71-02.news.clara.net...
Yes, the rest is 'lost' to the directory structures etc after formatting.

The directory structures etc, and in your case with RAID,
what gets used to keep the RAID info on the drives.

Grunff wrote:

The drive manufacturer reports unformatted capacity--since they don't know
what file system you're going to be using they can't report anything else
and have it mean anything. When the drive is formatted a certain amount of
space is taken up by the structures the operating system uses to keep track
of which file is in which sector and provide services such as journalling.
The capacity that the OS reports is what's left after that has been done.

To take one well known example, the common 3.5" HD diskette has an
unformatted capacity of 2 meg, but formatted under DOS its capacity is
reduced to 1.44 meg.


--
--John
to email, dial "usenet" and validate
(was jclarke at eye bee em dot net)

It is 400GB / 1.024^3 = 370GiB.

"Grunff" <grunff@ixxa.com> wrote in message
news:1114636289.17707.0@nnrp-t71-02.news.clara.net...
S>

"Grunff" <grunff@ixxa.com> wrote in message news:1114636289.17707.0@nnrp-t71-02.news.clara.net
and 1 kilobyte = 1000 bytes.

and 1 kilobyte = 1024 bytes.

Yes it does.

372*1024B*1024B*1024B = 399.432GB = ~400GB
373GiB -> 400.5 GB, The 372 was likely rounded.


Nope.

"Rod Speed" <rod_speed@yahoo.com> wrote in message news:3dae7jF6qhor1U1@individual.net
Clueless.

Utter nonsense.

J. Clarke wrote:


Sorry, perhaps I wasn't clear - this is the disk size reported by the
motherboard, before the disks have been formatted.


--
Grunff

OS>
No, it is the same explanation:
kBytes to KBytes conversion takes 1.024
mBytes to MBytes conversion takes another 1.024
gBytes to GBytes conversion takes yet another 1.024

Now calculate:
372*1.024*1.024*1.024=399.432
assume you had not exactly 372 but 372.499999
372.499999*1.024*1.024*1.024=399.969
I think that is close enough to 400gB, ooops, they say 400GB ;-)

Peter wrote:


Ahh...that makes sense. Many thanks.


--
Grunff

Well, the basis of the measurement of a bit (Binary digIT) is of course
binary. A byte = 8 bits, and traditionally, these measurements are
portrayed in powers of two. So, it makes sense to represent bits or
bytes in powers of two. Of course, decimal arithmatic is more natural
for most people to compute (and it's probably easier to market products
with nice, round numbers), so there are tradeoffs.

//Kevin

Kevin Buffardi <kevin.buffardi@email.com> wrote in message
news:427044da$0$79459$14726298@news.sunsite.dk...

Thats not what base 2 means in this situation.

Thats just plain wrong. The 1.44MB floppy
is in fact a weird binary/decimal hybrid.

Only when the total bytes are binary organised.
They aint with a hard drive or the cpu speed either.

And is the SI standard.

Its much more complicated than that, as the 1.44MB floppy shows.

I suggest you read "The Principles of Computer Hardware" (Alan
Clements). It lays out the foundation of computer hardware in decimal
arithmatic. The acronym "bit" itself comes from Binary digIT, 0 or 1.
It's the origin of terminology, so yes, *traditionally*, bits are
represented in powers of two.

Note the word "traditionally." Not "always," but "traditionally."

Misspoken: "Binary arithmetic."

Kevin Buffardi <kevin.buffardi@email.com> wrote in message
news:42706469$0$79454$14726298@news.sunsite.dk...

Most obviously with hard drives. Also with telecoms.

Dont need to, I know that is just plain wrong.

And I've been doing it since before Clements has too.

Irrelevant to that particular pig ignorant claim.

I didnt even comment on that.

Its still just plain wrong. Its only really been true of memory. And
that is because it does have an intrinsically binary ORGANISATION.

Well that was my comment. Then you said it was wrong.

I'm sorry if my first post was misleading, but I believe you are
misinterpreting it from my intentions. I never mentioned memory or
storage. I am talking about the origin of the terms bit and byte.
Those origins predate the use of the magnetic, non-volatile storage we
use today.

Both Peter and Folkert showed how binary arithmetic demonstrates the
difference between advertised size, and size represented in binary.

Your explanation of space taken by directory structures and such would
hold some credence if the disk was already formatted. However, Grunff
specified that the disk in question was unformatted and reported as
370GB by the motherboard (presumably in CMOS/BIOS).

//Kevin

Kevin Buffardi wrote:
Yes, upon reinspection I can see where I left too much of your quoted
text in, implying that I was referring specifically to storage capacity
when I was not. My apologies.

//Kevin

Folkert Rienstra wrote:

Yup, got it now, thanks.


--
Grunff