Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 23 Dec 1999 13:15:31 +1030
From:      Mark Newton <newton@internode.com.au>
To:        Ryan Thompson <freebsd@sasknow.com>
Cc:        freebsd-hackers@FreeBSD.ORG
Subject:   Re: Default minfree performance restrictions?
Message-ID:  <19991223131531.C17257@internode.com.au>
In-Reply-To: <Pine.BSF.4.10.9912221919590.49628-100000@sasknow.com>
References:  <Pine.BSF.4.10.9912201504420.30072-100000@sasknow.com> <Pine.BSF.4.10.9912221919590.49628-100000@sasknow.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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 <ryan@sasknow.com>
 > >   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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19991223131531.C17257>