No one seems to have addressed your question re. fragmentation, so I'll
offer my own limited understanding.  I may answer your question
satisfactorily, or I may attract the attention of someone who can give a
better answer on this topic.  (^&

Fragmentation is undesirable, but non-fatal.  The only time that I've ever
seen a notice about fragmentation on my system is after a crash (which
happened occasionally in 1.4---1.4.1 fixed that---and also happens during
power outages, if any...).  At that time, the system realizes that the
filesystem isn't entirely sane, and analyzes/repairs it.  In the process,
it appears to develop its notion of filesystem fragmentation.

(More technically, if /fastboot doesn't exist when the /etc/rc script is
run, then /etc/rc runs fsck.  I believe that fsck is where/when
fragmentation reports are printed.  I don't boot my system, much less
crash it, often enough to be 100% sure of that, and haven't successfully
located where in the system sources/scripts fragmentation is printed.)

As far as I know, the system only performs a check of filesystem
fragmentation at that time.  This fact alone should suggest that
fragmentation isn't a major issue (BSD systems can run for years on end
without being shutdown/rebooted).


There are some questions that you may or may not have, then:

 * What is fragmentation?  (You may know this already...but just in
   case...)  Ideally, files are laid out in a manner convient for fast
   reading (or perhaps rewriting) of successive blocks.

   When a file is fragmented, however, its bits may be scattered around in
   rather inconvenient places, requiring the drive to move the head more
   around the disk and to wait longer for drive rotation to bring the
   (file-sequentially) next block under the drive head.  Exactly how much
   effect this has depends on a number of things.  However:

    * It is never fatal that I know of, unless you have some very
      time-sensitive actions to take.  Unless you have something truly odd
      in your system, the worst that you are likely to see is sluggish
      file-system operations.

    * It is essentially never beneficial.  (You can contrive situations
      where ``properly'' fragmented files make certain random-access
      operations easier, but such fragmentation would be a bizarre fluke,
      at best.)  If the drive is screamingly fast, however, and you have
      it hooked up by a very slow interface...

    * 5% fragmentation probably isn't going to affect things much.  If you
      have more than 10% of your _diskspace_ free, the kernel sources
      claim that fragmentation never gets high enough to be a problem.
      (Run ``df'' on your system to see how much space you are using.  If
      it's less than 90%, then you can probably more or less ignore
      comments about filesystem fragmentation.)

 * Related: What is fragmentation measuring?  Upon reflection, it seems
   clear that it would be easier to measure the fragmentation of the
   unused space---although measuring the fragmentation of the _files_
   would give more useful information.  Offhand, I don't know which.
   (Anybody? I'm having trouble even finding out for sure where this
   is determined---I assumed fsck, but appear to be mistaken.)

   (If unused filesystem space is badly fragmented, then
   any large new files will likely have to be broken into
   fragments.  So, unused-space fragmentation gives an
   esimate of fragmentation of later files---and also may
   indicate existing files are likely to have been fragmented,
   already.)

 * What causes it?  Essentially, deleting files.  When disk-space is taken
   up by one file, then the next file that needs space has to go somewhere
   else.  Deleting the first file, then, leaves a ``hole'' in the
   filesystem.  Truncating files can have a similar effect.  To a lesser
   extent, files that slowly grow over time can get fragmented as they are
   given new filesystem blocks on an as-needed bases.

 * How do you fix it, if you are of a mind to do so?  The easy, low-tech
   solution is to back up important stuff, clean off the drive, and
   reinstall everything, being careful not to create many temporary files
   in the process (e.g., install packages as binary packages, or don't
   delete the work directories).  This should be highly effective,
   provided that you are willing to do the backup & reinstall work.

   I don't know of any defragmentation tools, in the standard system or in
   packages.  If you have enough [virtual] memory to hold the largest
   file, a filesystem-independant defragger could be written which reads
   as many files as memory will hold, deletes the old file[s], and then
   rewrites them, restoring all protect bits and resetting the access time
   (I'm not 100% sure that resetting all of the access/creation times is
   possible, but I think that it is).  It won't be perfect, but it
   might help a fragmented system---especially if you have a vast amount
   of memory.  By fiddling with ownership of directories in which it is
   modifying files, and perhaps with some modification to system daemons
   (adding tolerance to temporarily inaccessible dirs/files), you might be
   able to defrag any ``hot'' filesystem this way.

   A more effective defragger would have to be filesystem-specific.
   It would presumably run only on unmounted filesystems, however, so you
   couldn't run it while users (including daemons) were trying to do
   anything with the filesystem.  (^&

   If you run a multi-OS machine, you may have other filesystems than the
   native NetBSD filesystem; some of those may be defrag'able by another
   OS, by by some 3rd party tool.


The short of it:

It's not terribly important.  If you always have more than 10% of your
drive free, then whatever the fragmentation percentage reports, you
probably are okay (the FFS kernel sources claim to minimize fragmentation
well, in general).  I, personally, know of no simple tools to clean up a
fragmented disk, though a backup/wipe/restore will essentially fix it.

Good luck.  Hopefully someone with more knowledge & experience will
clarify & correct anything that I've mis-stated.  (^&


  "I probably don't know what I'm talking about."  --rkr@rkr.kcnet.com