Change size of hard drive in gparted

[bigpup]

Manufactures of hard drives always identify the size based on the smaller number used to calculate size.
Makes it look bigger than it really is.

1GB=1000×1000×1000 Byte

Operating systems use this actual byte number.

1GB=1024×1024×1024 Byte

In the operating system and it's programs.
a 120GB drive will show as 111.76 GB

[april]

Manufactures of hard drives always identify the size based on the smaller number used to calculate size.
Makes it look bigger than it really is.
1GB=1000×1000×1000 Byte
Operating systems use this actual byte number.
1GB=1024×1024×1024 Byte
In the operating system and it's programs.
a 120GB drive will show as 111.76 GB

Just trying to make sense of that
1024 x 1024 x1024 =10,737,418 x 120=128,849,010,000

1000x 1000x 1000 = 10,000,000 x 120=120,000,000,000

and a byte is 8 bits so these x 8 ? 960 Gigabits
No its not clear yet
So where does the 111.76 come from ?
I always assumed the loss was partition FAT tables , formatting indexes and records node lists etc

[disciple]

120/128...*120=111.76
(Sorry, posting from a phone)

[april]

120/128 x 120 = 112.5


120/128.849010 x 120 = 111.75871 (corrected rcrsn51)
But even so why would a ratio apply?

I would think its capacity is 128.9Gig in data size regardless and 17 and a bit Gigs are used up in housekeeping which is just huge anyway.

[rcrsn51]

120/128.849010 x 128.849010 = 138.35054

That's the wrong calculation. (12/3*3=12)

It should be

Code: Select all

120 / 128.849010 x 120

Or simply

Code: Select all

120/1.073741

Hard drive manufacturers use "G" as the official metric prefix - 10 to the power 9 (one billion).

But computers have traditionally worked in binary. So "K" means 2 to the power 10 and "M" means 2 to the power 20.

So "G" should mean 2 to the power 30, which is slightly bigger than 10 to the power 9. To avoid confusion, this prefix is called "Gi".

Makes it look bigger than it really is.

So it depends on how you are counting the individual bytes - in powers of 10 or powers of 2.

------------------------

GParted shows the raw size of the partition. The amount of space actually available to the user could be identified by Linux commands like df.

[april]

No I still can't say its clear.
A Kilobyte is 1024 bytes
A megabyte is 1,024,000 bytes
A megabit is 1,024,000 bits
A megabyte is therefore 1,024,000 x 8 = 8,192,000 bits

How am I doing so far? Crikey I've lost it now .(corrected rather than leave error here)

A Gigabyte is 1000 Megabytes isn't it ?
So a Gigabyte is 1000 x 1,024,000 bytes = 1,024,000,000 bytes
So 120 Gigabytes is 120 x 1,024,000 bytes = 122.880.000,000 bytes. ?

Code: Select all

root# df /dev/sda1
Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/sda1      115344936 64914808  44570852  60% /initrd/mnt/dev_save
root# 

115,344,936 X 1024=118,113,200,000 bytes ? ....nearly 2Gig lost here
File system is ext2.
I think I'll forget it and go have a beer

[rcrsn51]

A megabyte is 1024 bytes
A Gigabyte is 1000 Megabytes isn't it ?
So a Gigabyte is 1000 x 1024 bytes = 1,024,000 bytes

No. Mega means million. So Mega is 1000x1000 or 1024x1024, depending on which counting system you are using.

But you shouldn't mix them in the same calculation.

For a hard drive manufacturer, Giga probably means 1000x1000x1000, not 1000x1024x1024.

For a RAM manufacturer, Giga probably means 1024x1024x1024.

But you don't really know unless they tell you.

----------------

[jafadmin]

bits = bytes x 8 ( how data transfer speeds are measured - bps )

Bytes in Hex notation: (how volume is measured)

1024 = 1K
1024 x 1024 = 1M
1024 x 1024 x 1024 = 1G
1024 x 1024 x 1024 x 1024 = 1T

Marketing departments like to use decimal notation to make their products appear
bigger than their competitor's. a 500 G drive in hex would magically become a 520 G drive using decimal notation, etc ..

It's like monitor manufacturers using diagonal measurements instead of horizontal measurements.

[rcrsn51]

a 500 G drive in hex would magically become a 520 G drive using decimal notation

Calculation, please.

[jafadmin]

a 500 G drive in hex would magically become a 520 G drive using decimal notation

Calculation, please.

Ok, busted. My bad. It would be:

536,870,912,000 or 536G (dec)

1024x1024x1024x500

The problem is that the engineers who build these things are using hex notation to build them, then the marketing guys are using whatever the hell they want to use to market and sell them to naive consumers.
Here: Interesting read
In sales & marketing, ambiguity = Buck$
.

[rcrsn51]

The "fdisk -l" command shows you the total number of INDIVIDUAL byes on the drive. There is no confusion in that number.

You then have two ways to convert the number to a more convenient form - divide by powers of 1000 or divide by powers of 1024.

Since Gparted shows april's drive in GiB's, it's working with 1024. This is probably because other measurements are that way too.

For example, a 4KB block size is 4096 bytes, not the metric 4000 bytes.

[jafadmin]

Agree that fdisk will show the real story.

In my own case, I care about block size and number of blocks. Then I do the math on my fingers.

The reason for all the madness is that it makes simple sense in hexadecimal:
Block size 512 = 200h
Block size 1024 = 400h
Block size 4096 = 1000h

[april]

fdsk =119,997,988,864 bytes as opposed to
115,344,936 X 1024=118,113,200,000 bytes under df report

Code: Select all

root# fdisk -l /dev/sda1
Disk /dev/sda1: 111.8 GiB, 119997988864 bytes, 234371072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Now there must be a clear reason for that discrepancy
and
Disk /dev/sda1: 111.8 GiB so we are down 6.3 Gig on marked capacity.
118.113G
111.800G
...6.313G
I'm almost scared to use "/mnt/sda1" and see what comes up there !

[rcrsn51]

... as opposed to 115,344,936,000 bytes under df report

Where did you get that number?

[april]

Code: Select all

root# df /dev/sda1
Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/sda1      115344936 64914808  44570852  60% /initrd/mnt/dev_save
root# 

[rcrsn51]

Multiply by 1024, not 1000.

[april]

OK all these knowledgeable interjections but nothing comprehensive .
I have adjusted my posts where I think you are suggesting fixes

So Why the 6.313 Gig difference in reports from "df" and "fdisk -l"...?

Only one can be correct.

[rcrsn51]

This may be the difference between the amount of raw space on the disk and the amount of workable space available to the end user.

[jafadmin]

OK all these knowledgeable interjections but nothing comprehensive .
I have adjusted my posts where I think you are suggesting fixes

So Why the 6.313 Gig difference in reports from "df" and "fdisk -l"...?

Only one can be correct.

They are both correct. They measure different things.

df measures free space on mounted disk partitions. fdisk reports on the raw disk device metrics.

So fdisk shows raw disk, df shows cooked disk space, got it? Raw and cooked!

What is the raw weight of a ribeye, and what is the cooked weight? Inquiring mimes want to know! Yes, MIMES!!

[april]

Well I breed Droughtmaster Stud Bulls for sale and If their meat lost that much in the cooking I would change brands.

Thanks anyway