On Tue, 14 Apr 1998, Jim Reid wrote:

> 		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.
>

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

>     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.
> 

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

> 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.

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

--Sean