From owner-freebsd-hackers Wed Dec 22 18:46:17 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gizmo.internode.com.au (gizmo.internode.com.au [192.83.231.115]) by hub.freebsd.org (Postfix) with ESMTP id 615F315654 for ; Wed, 22 Dec 1999 18:46:12 -0800 (PST) (envelope-from newton@gizmo.internode.com.au) Received: (from newton@localhost) by gizmo.internode.com.au (8.9.3/8.9.3) id NAA17353; Thu, 23 Dec 1999 13:15:31 +1030 (CST) (envelope-from newton) Date: Thu, 23 Dec 1999 13:15:31 +1030 From: Mark Newton To: Ryan Thompson Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Default minfree performance restrictions? Message-ID: <19991223131531.C17257@internode.com.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: X-PGP-Key: http://www.on.net/~newton/pgpkey.txt Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Dec 22, 1999 at 07:25:39PM -0600, Ryan Thompson wrote: > 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? :-) The idea has merit, but you might need to increase the size of your cylinder groups to compensate if you lower the MINFREE threshhold which invokes space optimization. If UFS cylinder groups are too full the filesystem starts to find it difficult to find free blocks which are "geographically" close to the region of the disk inhabited by a file you're appending to, which reduces perforance. As such, you should build a filesystem with, perhaps, newfs -c32 (or whatever) before lowering the threshhold. > 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? I'm sure if you send-pr a patch which turns the threshhold into a sysctl variable which defaults to 5 you might end up with some careful consideration being given to the idea... - mark > On Mon, 20 Dec 1999, Ryan Thompson wrote: > > > 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 -- Mark Newton Email: newton@internode.com.au (W) Network Engineer Email: newton@atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message