From owner-freebsd-stable@FreeBSD.ORG Wed Jan 10 12:09:06 2007 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EBD4116A510 for ; Wed, 10 Jan 2007 12:09:06 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.freebsd.org (Postfix) with ESMTP id 5CC0313C45D for ; Wed, 10 Jan 2007 12:09:06 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (enmbcn@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id l0AC900d090062; Wed, 10 Jan 2007 13:09:05 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id l0AC8xUV090061; Wed, 10 Jan 2007 13:08:59 +0100 (CET) (envelope-from olli) Date: Wed, 10 Jan 2007 13:08:59 +0100 (CET) Message-Id: <200701101208.l0AC8xUV090061@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG, ghelmer@palisadesys.com, koitsu@FreeBSD.ORG In-Reply-To: <20070109195124.GA72863@icarus.home.lan> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Wed, 10 Jan 2007 13:09:05 +0100 (CET) Cc: Subject: Re: 6.x loosing record of free space after filesystem fills? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG, ghelmer@palisadesys.com, koitsu@FreeBSD.ORG List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2007 12:09:07 -0000 Jeremy Chadwick wrote: > Oliver Fromme wrote: > > Guy Helmer wrote: > > > I think we've finally found the cause of the problem - it wasn't just > > > occurring after heavy use, but was visible right after filesystem > > > creation! We regularly built new filesystems with "newfs -U -O 1 -b > > > 65536 -f 8192" > > > > Why are you using those blocksize and fragsize settings? > > (If you store large files, then you should at least also > > decrease the inode density, using the -i option.) > > Hmm... that begs the question: how do newfs -i and tunefs -f > associate with one another? Not at all. newfs -i specifies the inode density of the new file system, and it cannot be changed later on with tunefs. (There are file systems that allocate inodes dynamically, but our UFS isn't one of them.) So this puts a hard limit on the number of files that can be stored on the file system. The tunefs -f option (equivalent to newfs -g) can be used to optimizes the way file data blocks are distributed across cylinder groups. The purpose is to minimize frag- mentation and seek times. It does not change the number of inodes at all. > Shouldn't we document this somewhere? Some places I can think > of, off the top of my head: I think the most important settings (-i, -b, -f) are already sufficiently documented in the tuning(7) manpage. A link to tuning(7) should probably be included in the newfs(8) and tunefs(8) manpages. I haven't examined what the Handbook says about all of this, but I don't think that it makes sense to duplicate the manpage to the handbook. Instead, it would be helpful to include a pointer to the tuning(7) manpage there, too. Just my two cents. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "Documentation is like sex; when it's good, it's very, very good, and when it's bad, it's better than nothing." -- Dick Brandon