The message indicates that the file system code thinks there are too
many fragments on the filesystem to continue allocating space in a manner
which is optimized for time.  Then, as the file system fills further, the
threshold of fragmented files drops to the point where the file system code
can switch back to optimizing allocations for time.  It's the old speed
versus efficiency trade off.  On most filesystems, you won't see this
message, but on filesystems, like news servers and, I would guess web
caches, where there are a lot of small files which do not fill up entire
disk blocks, you'll get this fragmenting behavior.  The messages tell you
that the filesystem code is trying to minimize disk fragmentation and
insuring that you get a good balance of speed versus efficiency in your
disk allocations.  The messages are not indicative of an underlying
problem, although they are somewhat misleading in this day and age of fake
disk geometries and the like.  If I were you, I would ignore the messages
and monitor performance of the caching server instead.  If you cannot live
with the messages, try newfsing your cache with a smaller block size, 4096
versus 8192 for example.  
-Brian

On Oct 9,  3:45pm, Thilo Manske wrote:
} Subject: Problems with FFS optimization changes SPACE<->TIME
} Well, it's not really NetBSD-current (system runs 1.3.2) related, sorry
} for that.
} 
} PREAMBLE:
} 
} Last saturday night/sunday morning I upgraded our web proxy from
} Squid.1.NOVM.22 to Squid.2.0.RELEASE1. Since 2.0 uses a different cache
} structure as 1.x I had to clear the disk cache. I've decided to newfs
} the cache partition (~3GB) instead of deleting thousands of files.
} 
} PROBLEM:
} 
} As the cache started to fill up this week I noticed
} "Oct  8 16:57:32 Server /netbsd: /usr/local/squid/cache: optimization
} changed from TIME to SPACE" in /var/log/messages.
} 
} `df` said that the partition was around 33% full
} `fsck -n` nothing special and
} `tunefs -N` that everything was alright (except optimization)
} 
} Even more strange, as the cache filled up to around 36% I got:
} Oct  9 10:46:41 Server /netbsd: /usr/local/squid/cache: optimization
} changed from SPACE to TIME
} 
} So, my questions are:
} * What may cause this optimization switching? (I noticed it before - but
}   with ~95% full cache, so I thought it was normal)
} * Have I've done something wrong?
} * Is it a worth a PR?
} * Is it potentially dangerous?
} 
} TIA,
}   Thilo Manske.
} 
} 
} APPENDIX:
} 
} The system is an i386 (if it matters) and the partition is on an IBM UW
} connected to an Adaptec 2940UW. Uptime now around 64 days.
} 
} Kernel is NetBSD1.3.2 with these (maybe) related options:
} options QUOTA           # UFS quotas
} options NFSSERVER       # Network File System server
} options FIFO            # FIFOs; RECOMMENDED
} options NMBCLUSTERS=3D1024
} options KMEMCLUSTERS=3D2048
} options MAXVNODES=3D8000
} options AHC_TAGENABLE                   # tagged Command queueing
} options AHC_SCBPAGING_ENABLE            # SCB-paging
} (If anybody wants to see it i can mail/post the complete config file)
} 
} Output from tunefs now:
} tunefs: current settings
}         maximum contiguous block count 8
}         rotational delay between contiguous blocks 0ms
}         maximum blocks per file in a cylinder group 2048
}         minimum percentage of free space 5%
}         optimization preference: time
}         track skew 0 sectors
} 
} The partition is mounted with
} /dev/sd0g       /usr/local/squid/cache  ffs     rw,noatime 0 4
} in /etc/fstab
} 
} The label of the disk looks like:
} # /dev/rsd0d:
} type: SCSI
} disk: ibmdchs
} label: dchs04u
} flags:
} bytes/sector: 512
} sectors/track: 162
} tracks/cylinder: 9
} sectors/cylinder: 1458
} cylinders: 6077
} total sectors: 8860266
} rpm: 3600
} interleave: 1
} trackskew: 0
} cylinderskew: 0
} headswitch: 0           # milliseconds
} track-to-track seek: 0  # milliseconds
} drivedata: 0
} 
} 7 partitions:
} #        size   offset    fstype   [fsize bsize   cpg]
}   a:    34992        0      4.2BSD     1024  8192    16   # (Cyl.    0 - =
} 23)
}   b:   368874    34992        swap                        # (Cyl.   24 - =
} 276)
}   c:  8860266        0      unused        0     0         # (Cyl.    0 - =
} 6076)
}   d:  8860266        0      unused        0     0         # (Cyl.    0 - =
} 6076)
}   e:    43740   403866      4.2BSD     1024  8192    16   # (Cyl.  277 - =
} 306)
}   f:  1650456   447606      4.2BSD     1024  8192    16   # (Cyl.  307 - =
} 1438)
}   g:  6762204  2098062      4.2BSD     1024  8192    16   # (Cyl. 1439 - =
} 6076)
} 
} (In-core and on-disk labels are identical, I've checked it.)
} --=20
} Mir ist mein Signature entlaufen :-(. Wer es findet, sende es bitte an
} Thilo.Manske@HEH.Uni-Oldenburg.DE zur=FCck. Danke!=20
>-- End of excerpt from Thilo Manske