ext2 file system overhead!!
Sasan Iman
I have a 100gig hd turned into two 50gig partitions each and did mkfs
for ext2 on each partiitons. I get only about 40gig disk capacity on
each partition.
Where is the other 10gig?!!!!! Is it eaten up by the filesystem related
information?!!!!
Thanks,
Sasan
rnic...@interaccess.com
Sasan Iman <im...@simantis.com> wrote:
:
:
:
:I have a 100gig hd turned into two 50gig partitions each and did mkfs
Overhead in a large ext2 file system is typically under 2%, and that's
with a fairly generous allocation of 1 inode per 2 data blocks. If you
look at the output from "tune2fs -l" for your ext2 partition you can
calculate the ratio of Inode_blocks_per_group/Blocks_per_group.
OTOH, the ratio of a decimal Gigabyte (1,000,000,000 bytes) to a binary
Gigabyte (1,073,742,824 bytes) is more like what you are seeing. Add in
the ext2 overhead, and yes, that's getting pretty close to 10%.
--
Bob Nichols rnic...@interaccess.com
Sasan Iman
Very interesting!! So when I buy a 100Gig hard drive, am I buying a 100gig
decimal or 100gig binary?!
SI
Stephen Cormier
1k = 1024 bytes, 1mb = 1,024,000 and 1gb = 1,024,000,000 that being
the case you get a 2.4% loss due to formating which leaves you with
~97.6gb take off an additonal 2% = ~95.7gb which gives you a 4.3%
loss not 10% and beside that fact he actually has a 20% loss 40gb vs
50gb per partition he is saying 10gb per partition. So I think there
must be something wrong with the way the drive was partitioned or
with the BIOS not being able recognize the size of the HD.
--
May the source be with you!
Stephen Cormier
Yes HD makers use 1000 bytes to = 1K where as it is really 1024 bytes
= 1k so your 100gb is ~ 97.6gb when formated, a dirty trick I know
but this has been going on forever you have to read the fine print on
the box or manual to see what the formated size is. I read your
earlier post and I just can not see how you would have that kind of
loss of space on the HD ( 40gb vs 50gb = 20% loss ). Have you checked
to see if your BIOS supports partitions that large or the mkfs has
such support because it seems to me that either one or the other is
not seeing the real size of your HD, I have never lost that much
space formating.
Adaptrx
news:Xrhm8.2$kN6...@sapphire.mtt.net...
> Yes HD makers use 1000 bytes to = 1K where as it is really 1024 bytes
> = 1k so your 100gb is ~ 97.6gb when formated,
Nope.
100 G in harddrive manufacturer's parlance is indeed 100 billion bytes, but
this is definitely not 97.6 GB.
Please use a calculator next time ?
100,000,000,000 / 1024 = 97,656,250 KB
97,656,250 KB / 1024 = 95,367.43 MB
95,367.43 MB / 1024 = 93.13 GB
So that's almost 7 percent you "lose" (It was never there anyway...)
Now, for the file system overhead.
Straight from the mke2fs man pages:
"-m : reserved-blocks-percentage : percentage of blocks reserved for the
super-user, DEFAULTS TO 5%"
A block is 1 K by the way, but that's irrelevant:
IF you don't set this to 0% specifically, as I do with large data-only
drives,
you ALWAYS lose 5% of the capacity to space reserved for root.
So, 5% of 93.13 GB (I'm lumping both partitions together here, doesn't
matter at this point)
is another 4.66 GB lost to that, for a total of 6.87 + 4.66 = 11.53 GB
So you're down 11.5 percent and the drive isn't even formatted yet !
Now I don't know exactly how much space the filesystem itself will take up,
as this depends on the number of inodes, the number of superblocks and
backup blocks, etc.
But I think you see where this is going...
Next time, use the "-m 0" option to skip the reserved blocks and you'll have
gained an instant 4.65 GB !
> Have you checked to see if your BIOS supports partitions that large or
the mkfs has
> such support because it seems to me that either one or the other is
> not seeing the real size of your HD, I have never lost that much
> space formating.
> --
I can assure you that the BIOS has nothing whatsoever to do with it,
as partitions are not made by, for or in the BIOS, they are solely an
abstraction used by the OS.
And if you haven't seen this kind of lossage, try formatting it with
FAT16...
HTC (happy to correct :-)
rnic...@interaccess.com
Stephen Cormier <scor...@nospam.com> wrote:
:1k = 1024 bytes, 1mb = 1,024,000 and 1gb = 1,024,000,000 that being
:the case ...
But that is not the case.
1 binary kilobyte = 1024 bytes
1 binary megabyte = 1024^2 bytes = 1,048,576 bytes
1 binary gigabyte = 1024^3 bytes = 1,073,741,824 bytes
1 binary terabyte = 1024^4 bytes = 1,099,511,627,776 bytes
The use of the "binary" version of the prefixes came about because
computer addressing grows naturally in powers of 2, and when "kilobytes"
was the commonly used unit of measure the difference between the binary
unit and the standard decimal unit was fairly insignificant. For
computer memory sizes, disk partition sizes, etc., the binary
definitions are common usage. For capacities of disks and tapes, data
transmission rates, and basically anything where the marketing
department would like to see a larger number, the ISO standard
power-of-ten definitions apply. Unfortunately, as you move up to
megabytes, gigabytes and beyond the percentage difference grows.
--
Bob Nichols rnic...@interaccess.com
Stephen Cormier
You are right made a slight error in the calculations :) but that
still only leaves a 7.3% loss plus the 2% overhead for the file
system which = 9.3 % total not the 20% he is talking about.
Stephen Cormier
> "Stephen Cormier" <scor...@nospam.com> wrote in message
> news:Xrhm8.2$kN6...@sapphire.mtt.net...
>
>> Yes HD makers use 1000 bytes to = 1K where as it is really 1024
>> bytes = 1k so your 100gb is ~ 97.6gb when formated,
>
> Nope.
> 100 G in harddrive manufacturer's parlance is indeed 100 billion
> bytes, but this is definitely not 97.6 GB.
> Please use a calculator next time ?
> 100,000,000,000 / 1024 = 97,656,250 KB
> 97,656,250 KB / 1024 = 95,367.43 MB
> 95,367.43 MB / 1024 = 93.13 GB
> So that's almost 7 percent you "lose" (It was never there anyway...)
You are correct in that I did not use the correct binary reduction
but I was saying to him was that the capacity as labeled is false and
that HD manufactures choose to decieve people so that they think they
have more space.
Always used multipe partitions to maximize the use of the space on
FAT16 but you did not lose the formatted capacity of the HD due to
the large block sizes just the efficient use of the space ie. many
small files taking up too much space that was the whole idea behind
FAT32 better use of the space not extra formatted capacity.
>
> HTC (happy to correct :-)
No problem learned a couple of things do not do quick calculations in
your head and the -m 0 is gonna get me some extra space on the next
HD I add to the system ;) .
Sasan Iman
Thanks to all for replying. The numbers I had posted were inaccurate, as in
one place I typed "I only get 40Gig per partition" but I meant to type
45Gig. At the time, I did not think this to be too important as I thought
even 5 Gig per partition (total loss of 10 gig) was too much.
Ok here are the accurate data:
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/hdb1 48070472 7534292 38094304 17% /xena1
/dev/hdb2 48078536 29819088 15817168 66% /xena2
Each partition is half of the 100gig drive (so should be 50gig). Also note
that (Used + Available != 1k-blocks).
Total usable disk space (Used+available) for both partitions are:
91264852 1k-block.
I'd say I am loosing about 9gig. Don't like it, but now understand where it
is going.
Si
rnic...@interaccess.com
Sasan Iman <im...@simantis.com> wrote:
:
:Ok here are the accurate data:
:
:Filesystem 1k-blocks Used Available Use% Mounted on
:/dev/hdb1 48070472 7534292 38094304 17% /xena1
:/dev/hdb2 48078536 29819088 15817168 66% /xena2
:
:Each partition is half of the 100gig drive (so should be 50gig). Also note
:that (Used + Available != 1k-blocks).
That difference is the reserved space, by default 5%. You can reduce
that percentage when you build the file system, or you can use tune2fs
to change it on an existing file system. But, be aware that an ext2
file system will lose its resistance to fragmentation if the amount of
free space falls much below 5%.
--
Bob Nichols rnic...@interaccess.com
Charles Sullivan
> Adaptrx wrote:
>
>> Now, for the file system overhead.
>> Straight from the mke2fs man pages:
>>
>> "-m : reserved-blocks-percentage : percentage of blocks reserved for
>> the super-user, DEFAULTS TO 5%"
>>
>> A block is 1 K by the way, but that's irrelevant: IF you don't set this
>> to 0% specifically, as I do with large data-only drives,
>> you ALWAYS lose 5% of the capacity to space reserved for root.
>>
>> So, 5% of 93.13 GB (I'm lumping both partitions together here, doesn't
>> matter at this point)
>> is another 4.66 GB lost to that, for a total of 6.87 + 4.66 = 11.53 GB
>> So you're down 11.5 percent and the drive isn't even formatted yet !
>>
>> Now I don't know exactly how much space the filesystem itself will take
>> up, as this depends on the number of inodes, the number of superblocks
>> and backup blocks, etc.
>> But I think you see where this is going...
>>
>> Next time, use the "-m 0" option to skip the reserved blocks and you'll
>> have gained an instant 4.65 GB !
>
> No problem learned a couple of things do not do quick calculations in
> your head and the -m 0 is gonna get me some extra space on the next HD I
> add to the system ;) .
Don't be too hasty! First find out _why_ those blocks are reserved.