From owner-freebsd-questions@FreeBSD.ORG Fri May 7 20:18:39 2010 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B9DFB1065676 for ; Fri, 7 May 2010 20:18:39 +0000 (UTC) (envelope-from freebsd-questions@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 473C58FC0A for ; Fri, 7 May 2010 20:18:39 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OAU0I-0003HJ-Dv for freebsd-questions@freebsd.org; Fri, 07 May 2010 22:18:34 +0200 Received: from pool-70-21-1-190.res.east.verizon.net ([70.21.1.190]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 07 May 2010 22:18:34 +0200 Received: from nightrecon by pool-70-21-1-190.res.east.verizon.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 07 May 2010 22:18:34 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-questions@freebsd.org connect(): No such file or directory From: Michael Powell Followup-To: gmane.os.freebsd.questions Date: Fri, 07 May 2010 16:17:43 -0400 Lines: 67 Message-ID: References: <20100507185752.GA24228@libertas.local.camdensoftware.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: pool-70-21-1-190.res.east.verizon.net Subject: Re: Space on root partition X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 20:18:39 -0000 Chip Camden wrote: > When partitioning the drive, I took the defaults -- which seems to create > a root partition that's too small. I'm at 59% usage, and every time I > install a new kernel I have to rm /boot/kernel.old to get it to go. > > Two questions: > > 1. Is there an easy way to resize partitions? It is not too much of a problem if it is the last partition followed by free space. But the location of / in the scheme of things generally precludes this. There are a few different approaches one can take to accomplish this, but my general feeling is doing so on a production box can invite disaster and you wind up with more problems than you started with. > 2. Is there anything in root I could safely symlink off to another > partition? I would tend to not want to go this route, as it is good to have / a fairly self-contained entity for recovery purposes. A lot of things can go wrong with a box, and if you can get to / in single user many may be fixable. > Here's a df: > > Filesystem 1K-blocks Used Avail Capacity Mounted on > /dev/ad4s1a 507630 273388 193632 59% / > devfs 1 1 0 100% /dev > /dev/ad4s1e 507630 18 467002 0% /tmp > /dev/ad4s1f 463086528 21941374 404098232 5% /usr > /dev/ad4s1d 4848462 201194 4259392 5% /var Example from one of my servers: Filesystem Size Used Avail Capacity Mounted on /dev/ad0s1a 193M 91M 87M 51% / [snip] The other approach would be to decrease the size of what is installed in /. The main question [criterion] you should use if you need to pursue this is exactly how much code debugging do you need to hold in abeyance? For instance, I only run Release on production boxen with the only maintenance for security branch updates. For me the bits have been very stable, but if you should ever need code debugging the following practice will be a problem. 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. Delete all of the symbol files in /boot/kernel and /boot/kernel.old. 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 will mitigate a / being too small, but at the cost of kernel code debugging. If you are running Release on production boxen which just sit there and do their job, you may be able to forego the debugging facilities. In a different situation such as following -STABLE or -CURRENT and the code changing from time to time, you may need the kernel debugging facilities to assist the developers with problem resolution. Whether you can use this approach depends on your situation, e.g., do I need debugging or can I get away without it? YMMV! -Mike