[vox-tech] resizing harddrive

[Mike Simons]

Since some people say Gigabytes are 10^9 and others 2^30.  To be consistent 
with units, I'll use bytes, MiB (2^20 == 1048576) and GiB (2^30 = 1073741824).  

On Thu, Feb 27, 2003 at 10:26:40PM -0800, Ryan wrote:
> okay so after backing everything up for 4 hours I did what you said:
> 
> The partition is indeed bigger, but not was large as I had expected. 
> It says I only have about 36GB free. Here is a df

Ryan,

  You had unrealistic expectations...

  You should have about 5.5 GiB more of available space than before.
That is hard to be certain about, because you didn't include the before
df in your email.


    TTFN,
      Mike


  Let's break a few things down...  here are the relevant log lines.

Real Disk Size:                 40020664320 B  38166 MiB   37.3 GiB
Lost to Filesystem Overhead:      320880640 B    306 MiB    0.3 GiB
===================================================================
Available Filesystem:           39699783680 B  37860 MiB   37.0 GiB
Lost to Reserved Blocks:         2000797696 B   1908 MiB    1.9 GiB
Lost to Journal Overhead:          33615872 B     32 MiB    0.0 GiB
===================================================================
Available to Users:             37665370112 B  35920 MiB   35.1 GiB


# hdb: 78165360 sectors (40021 MB) w/2048KiB Cache, CHS=4865/255/63, (U)DMA
# [...]
# CurCHS=16383/16/63, CurSects=-66060037, LBA=yes, LBAsects=78165360

  You're drive has 78165360 sectors (512 bytes each) or 
40020664320 bytes of space... which is 38166 MiB or 37.3 GiB.

> Filesystem           1k-blocks      Used Available Use% Mounted on
> /dev/hdb1             38769320     32828  36782588   1% /home/media

  The filesystem contains 38769320 usable blocks (1k bytes each) or 
39699783680 bytes (37860 MiB) or (37 GiB) of space.

Which means you lost about 0.8% or 40020664320-39699783680 = 320880640 
  320880640 bytes (306 MiB) do to hidden filesystem overhead... 

"Used = 32828 blocks" means another 
  33615872 bytes (32 MiB) are taken by the filesystem journal.


  You may notice that '1k-blocks' is 38769320, and 'Used' + 'Available'
is 36815416.  That is 2000797696 bytes or so... those 5% of blocks, are 
reserved to help prevent fragmentation, speed up writing, and other 
useful magic filesystem purposes.  (Reserved space is standard on 
any Unix filesystem I've ever used, some even reserve 10%).
  2000797696 bytes (1908 MiB) or (1.9 GiB)


I recommend not doing this...

  But if you want to totally want to destroy performance once you 
start using most of the 5% cushion of "reserved blocks"... you can 
set the number of reserved blocks to 0 with the following command:
  tune2fs -r 0 /dev/hdb1
I recommend unmounting the filesystem first.  


# /dev/hdb1             1      4111  33021576   83  Linux

  I can't exactly compare apples to apples, since I don't have a df from
before.  But the new partition is 6206570496 bytes or 5919 MiB or 5.8
GiB... larger, which should have gone almost straight to the available
blocks (minus the 5% reserved).


  The only possible correction was the -i 16384, you might have been better
with -i 32768... which would have cut into the 'Overhead' number above,
by creating fewer inodes, which would reduce the number of files you can
store.  If you haven't already reloaded the data onto the drive... you
can check out "df -i" to see how many inodes are available... that tells
you how many files you can have.  If the number is "too big" for what
you KNOW you need... run:
  mke2fs -j -b 4096 -i 32768 /dev/hdb1
... but we are talking about getting some of 306 MiB.