From owner-freebsd-questions@FreeBSD.ORG Wed May 21 04:02:44 2003 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A1AC637B401 for ; Wed, 21 May 2003 04:02:44 -0700 (PDT) Received: from gs166.sp.cs.cmu.edu (GS166.SP.CS.CMU.EDU [128.2.205.169]) by mx1.FreeBSD.org (Postfix) with SMTP id EA46B43F75 for ; Wed, 21 May 2003 04:02:43 -0700 (PDT) (envelope-from dpelleg@gs166.sp.cs.cmu.edu) Sender: dpelleg@gs166.sp.cs.cmu.edu To: Perica Veljanovski References: <20030521103711.3B2A.EZHE@euro.net.mk> From: Dan Pelleg Date: 21 May 2003 07:01:56 -0400 In-Reply-To: <20030521103711.3B2A.EZHE@euro.net.mk> Message-ID: Lines: 44 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: freebsd-questions@freebsd.org Subject: Re: no free inodes X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2003 11:02:44 -0000 Perica Veljanovski writes: > Hi, > I'm running Squid proxy whitch logs to mysql trough perl scripts on FreeBSD > 4.7-RELEASE. > > last week it froze and I had to do a hard reboot, and since then it's > showing strange errors. > > for example, vhenever I try to edit something in vi: > ------- > IBM:/usr/local/squid/sbin#vi example > /var: create/symlink failed, no inodes free > > +=+=+=+=+=+=+=+ > Error: /var/tmp/vi.recover: No space left on device. > Modifications not recoverable if the session fails; example: new file: > line 1 > Press any key to continue: > -------- > > allsow, somethimes when I reboot it shoes: "no inodes free" > > I'm not very experienced with FreeBSD, but it is stil my favuret :) > > So, what seems to be the problem here? Like the messages say, you ran out of inodes. This can happen if something (most probably squid) created lots and lots of tiny files. The band-aid solution would be to look in /var, find those files and delete them. To prevent this from recurring you want to tell the offending application to use a filesystem with more capacity. Most often this can be done with a symlink. The best thing to do long-term would be to create a filesystem that is better suited for small files. See the tuning(7) man page, search for "newfs". If you don't have disk space for a new filesystem you can even create one inside a file with vnconfig(8) - see the handbook for an example. -- Dan Pelleg