Disk Usage

Michael Powell nightrecon at hotmail.com
Fri Apr 23 16:33:56 UTC 2010

illoai at gmail.com wrote:

> On 22 April 2010 12:02, Jerry <freebsd.user at seibercom.net> wrote:
>> I just did a fresh install of FreeBSD-8.0/amd64. Previously, I had
>> FreeBSD-7.3/i386  installed. It appears the the size of "/" has
>> increased dramatically.
>> $ df -H
>> Filesystem     Size    Used   Avail Capacity  Mounted on
>> /dev/ad0s1a    1.0G    527M    428M    55%    /
>> devfs          1.0k    1.0k      0B   100%    /dev
>> /dev/ad0s1d    520M     18k    478M     0%    /tmp
>> /dev/ad0s1e    236G    6.0G    212G     3%    /usr
>> /dev/ad1s1d    238G    720M    218G     0%    /var
>> When I attempted to build World and a new kernel after first installing
>> 8.0, I received an error that "/" was at 106% and the process stopped. I
>> reinstalled 8.0 and increased the size to 1.0G and now everything
>> appears to be working correctly.
>> In my old installation, the root directory only used a minuscule amount
>> of space. Why has it increased so dramatically in 8.0/amd64?
> 64bit executables are going to be larger,
> sometimes as much as 2x, but do you
> now have a bunch of (large)
> /boot/kernel/*.symbols
> files now?

You can comment out 'makeoptions	DEBUG=-g' from your kernel config file, 
along with all other debugging facilities and set  WITHOUT_PROFILE= true in 
src.conf. I also have STRIP= -s in my make.conf, but IIRC this should only 
apply to ports builds.

The downside to this is if you need to do some serious troubleshooting 
you're screwed. On production boxen I run Release versions, and only do 
security updates/patches or upgrade to the next Release. In the past using 
the most quiescent code has been good to me.

After two kernel builds/installs the huge GENERIC gets moved out of the way. 
My i386 box has 91MB of space used in / and the 64 bit boxen are typically 
about 93-95MB. I only have one i386 box left and it's crunched down kernel 
is 4.2MB, and my 64 bit ones average around 4.5MB.

This can be an effective strategy to mitigate a / being too small, but at 
the cost of reducing one's ability to get down and dirty troubleshooting 
code bugs.


More information about the freebsd-questions mailing list