Subject: Re: tunefs , min free and autamatic optimisation policy changes
To: Sean Witham <Sean.Witham@asa.co.uk>
From: Jim Reid <jim@mpn.cp.philips.com>
List: netbsd-help
Date: 04/14/1998 11:45:25
>>>>> "Sean" == Sean Witham <Sean.Witham@asa.co.uk> writes:

    Sean> I recieved the followling message during a busy untaring
    Sean> session:

    Sean> Apr 9 19:11:07 newbuild /netbsd: /usr: optimization changed
    Sean> from TIME to SPACE
    Sean> I assumed that the partition had less than the usual 10%
    Sean> free but df /usr showed :

    Sean> Filesystem  1K-blocks    Used   Avail Capacity Mounted on
    Sean> /dev/sd0e     1637174  504610 1050705      32% /usr

    Sean> So I assumed it was high fragmantation level but fsck -n
    Sean> /usr showed a fragmantation of only 2%

See ffs_alloc.c:

	case FS_OPTTIME:
		/*
		 * ... If aberrant programs cause disk fragmentation to
		 * grow within 2% of the free reserve, we choose to begin
		 * optimizing for space.
		 */
		if (fs->fs_cstotal.cs_nffree <
				fs->fs_dsize * (fs->fs_minfree - 2) / 100)
			break;
		log(LOG_NOTICE, "optimization changed from TIME to SPACE\n");
		fs->fs_optim = FS_OPTSPACE;

So if the number of free fragments (fs->fs_cstotal.cs_nffree) is less
than (fs_minfree - 2) percent of the total number of data blocks, the
filesystem continues TIME optimisation. If not, it prints a message
and switches to SPACE optimisation.

    Sean> Has the kernel switched back to TIME optimisation and not
    Sean> announced it

If it hasn't, there's a bug.... Or maybe your syslog was bust when it
happened. ISTR some vendors added hacks to switch the optimisation mode
depending on how inodes were being used.

In any event, the optimisation code is next to useless for most of
today's hardware. All it does is determine whether a complete free
block gets assigned to an N-fragment write or not. Since most things
use the stdio library which writes blocksize amounts at a time, the
"optimisation" will rarely be used whenever the filesystem gets
full. It should also be remembered that UFS was designed around 15
years ago when a 400 Mb Eagle was a "big disk", 25ms disk latency was
"really quick" a 1 MIP VAX was a "fast machine" and the norm for I/O
through a V7 filesystem was 20-50 Kb/second. The optimisation and
placement policies of UFS then are probably of little significance for
today's disks and I/O subsystems.

    Sean> is there anyway to check the current acctive optomisation policy ?

Use dumpfs and look at what it prints out for fs_optim. Or use a
low-level debugger to look at the filesystem's superblock.