>>>>> "Sean" == Sean Witham <Sean.Witham@asa.co.uk> writes:

    Sean> is that likely with 2% fragmantation reported by fsck and
    Sean> disk usage of 32% reported by fsck ? With only a third of
    Sean> the disk used I'm surpried a fragmantation 2% would cause
    Sean> the number of usable free blocks to drop so low.

The fragmEntation percentage reported by fsck is not the same as that
used by the UFS code to switch on/off FS_OPTTIME. Read the code:

>From fsck:
		printf("(%ld frags, %ld blocks, %.1f%% fragmentation)\n",
			sblock.fs_cstotal.cs_nffree,
			sblock.fs_cstotal.cs_nbfree,
			(float)(sblock.fs_cstotal.cs_nffree * 100) /
			sblock.fs_dsize);


From: /sys/ufs/ffs/ffs_alloc.c:

		if (fs->fs_cstotal.cs_nffree <
			fs->fs_dsize * (fs->fs_minfree - 2) / 100)


The fragmentation reported by fsck is the number of free fragments
divided by the number of data blocks in the filesystem. The
fragmentation factor used by UFS for SPACE/TIME optimisation is if the
number of free fragments is (roughly) equal to minfree percent of the
data blocks in the filesystem.

    Sean> It did change back sometime later after the email was
    Sean> posted.  The usuall statistics don't give any indication
    Sean> when to expect this to occour or when to expect things to
    Sean> revert back to TIME optimsation.

Read the code.

    Sean> I have wondered if it was worth using something like tunefs
    Sean> and an up-to-date disktab entry for the SCSI disks I use by
    Sean> the sound of what you have mentioned above it hardly seems
    Sean> worth it.

Indeed. It's even less worth it with SCSI disks because the concept of
disk geometry is meaningless. Some disks have a variable number of
physical sectors per track depending whereabouts on the disk you are. 
Then there's sector slipping for bad block handling, etc, etc.

Another effectively useless tunefs parameter is fs_rotdelay - an
estimate of the number of milliseconds it takes the disk driver to
handle an interrupt. The idea was to optimise the physical placement
of the logical blocks of a file. Hopefully the N+1th logical block of
a file would appear under the disk heads just after the driver had
processed the interrupt for block N. [Unix processes tend to read
files sequentially.] Now this was a good thing in the days of 1 MIP
CPUs and stupid but simple SMD controllers. Today it's pointless:
modern disk controllers often have caches and read whole tracks or
cylinders at a time into their cache. If you suppose a disk interrupt
service routine takes ~5,000 instructions - probably an overestimate -
that will take 0.05 milliseconds on a 100 MIP CPU.