From owner-freebsd-hackers Wed Dec 22 17:25: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sasknow.com (h139-142-245-96.ss.fiberone.net [139.142.245.96]) by hub.freebsd.org (Postfix) with ESMTP id DCEE6156D0 for ; Wed, 22 Dec 1999 17:24:59 -0800 (PST) (envelope-from freebsd@sasknow.com) Received: from localhost (freebsd@localhost) by sasknow.com (8.9.3/8.9.3) with ESMTP id TAA49693 for ; Wed, 22 Dec 1999 19:25:39 -0600 (CST) (envelope-from freebsd@sasknow.com) Date: Wed, 22 Dec 1999 19:25:39 -0600 (CST) From: Ryan Thompson To: freebsd-hackers@freebsd.org Subject: Re: Default minfree performance restrictions? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hmm... Since I didn't get a single reply to this one, am I to assume that you all think I'm nuts, and should be publicly flogged with a copy of Greg's book for even thinking such foolish thoughts? :-) Or... Maybe most of the more knowledgeable individuals who follow this list are just gone for the holidays. Seriously, though, folks, does my idea make any sense at all? Thanks, - Ryan On Mon, 20 Dec 1999, Ryan Thompson wrote: > Hello all, > > After creating some larger slices than I'm used to, I finally felt the > full force of a default 8% minfree setting. So, I went to tunefs(8) to > try and put a damper on the multiple gigabytes that aren't being made > available to users. However, I was a bit disappointed to note that > setting minfree at or below 5% (using integer values!) would result in > SPACE optimization. > > So, on my 3.4-STABLE system, I did some hunting around. > > In /usr/src/sys/ufs/ffs/fs.h, I see MINFREE defaults to 8%, and default > time optimization, like tunefs says. Nothing fancy, there. > > In ./ffs_alloc.c, however, I found out how the SPACE/TIME optimization is > determined. In particular, in ffs_realloccg(), I find (from yesterday's > -STABLE), the following snippet: > > /* > * Allocate a new disk location. > */ > if (bpref >= fs->fs_size) > bpref = 0; > switch ((int)fs->fs_optim) { > case FS_OPTSPACE: > /* > * Allocate an exact sized fragment. Although this makes > * best use of space, we will waste time relocating it if > * the file continues to grow. If the fragmentation is > * less than half of the minimum free reserve, we choose > * to begin optimizing for time. > */ > request = nsize; > if (fs->fs_minfree <= 5 || /* !!! */ > fs->fs_cstotal.cs_nffree > > fs->fs_dsize * fs->fs_minfree / (2 * 100)) > break; > log(LOG_NOTICE, "%s: optimization changed from SPACE to TIME\n", > fs->fs_fsmnt); > fs->fs_optim = FS_OPTTIME; > break; > > Questions: > > - Can the line I've marked /* !!! */ have the minimum value of 5 safely > reduced? Eliminated? (safely = if/when a filesystem fills up, could writes > potentially corrupt the fs?) On small partitions with many inodes, perhaps > 5% is appropriate, but in cases like mine, where I have filesystems in > excess of 20GB with < 0.1% fragmentation, > 5% minfree is frankly too much > to give away. > > - Would it make sense to externalize this option into a header file, > kernel config option, or perhaps tunefs itself? I'm guessing the latter > would require modifications to our UFS implementation to allow for the > extra parameter for each filesystem... And would definitely qualify as an > "invasive" change. Food for thought, though :-) > > Any insights? > > I suppose I could just go ahead and try it, but, before I end up doing a > reinstall (cd /usr/src && make blowupworld), I thought it better to ask a > more experienced following of users :-) > > -- > Ryan Thompson > 50% Owner, Technical and Accounts > Phone: +1 (306) 664-1161 > > SaskNow Technologies http://www.sasknow.com > #106-380 3120 8th St E Saskatoon, SK S7H 0W2 > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message