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.