FSANALYZE - File System Analyzer tool
Version  : 4.1.1.2 - 88/11/30 15:53:38

Author   : Michael J. Young
USmail   : Software Development Technologies, Inc.
           375 Dutton Rd
           Sudbury MA  01776
UUCP     : harvard!sdti!mjy
Internet : mjy@sdti.SDTI.COM

   =========================================================================
   Note : This program has been placed in the public domain to permit
   unrestricted distribution and use.  I have placed no copyright on it, but
   I request that you keep me informed about any enhancements and bug fixes
   you make so I can keep an up-to-date copy for further distribution.
   =========================================================================

   This is a completely new version of fsanalyze which contains a number of
   bug fixes, new features, and enhanced portability.  This version of
   fsanalyze has been ported to the BSD fast file system, and run
   successfully on a Sun.  It has also run successfully under Ultrix,
   but some changes may be needed in the #include directives in
   the file "fsanalyze.h".

   For a complete revision history, see the file called "Changes".  Other
   useful information may be found in the file called "Info".

Introduction:
   Fsanalyze is a simple tool that estimates file system fragmentation.  It
   accomplishes this by scanning the data blocks for each i-node in the 
   file system, looking for block numbers that are out of sequence.  In
   effect, it is counting the number of disk seeks required to read the
   entire file in sequence.  Fragmentation is then computed as the ratio
   of actual "seeks" to the potential number of "seeks" if the file were
   completely fragmented.

   Fsanalyze also provides a number of other useful statistics regarding the
   file system usage, including the number (and identity) of files that are
   very large, sparse files, and excessively large directories (i.e.,
   directory files that require data block indirection, making filename
   searches very inefficient).
   
   After the general file system statistics are displayed, fsanalyze lists
   the 10 most fragmented i-nodes in the file system.  The 10 most
   fragmented files are listed in decreasing order of fragmentation based on
   the absolute number of fragments.  For example, a 100-block file that
   contains 40 individual fragments is 39.39% fragmented (39 seeks / 99
   potential seeks), but is listed before a 2-block file that contains 2
   fragments (100% fragmented).  Thus, larger fragmented files (which have a
   greater effect on file system performance) are listed before small files.

   In my estimation fsanalyze is completely safe, since it never writes to
   the file system that it is analyzing and uses only the standard I/O
   library to do its work.  It should be possible to run fsanalyze on a
   write-protected file system, if you're worried.  If anything should go
   wrong, the worst you will see is fseek() errors.  Be that as it may,
   however, there is no express or implied warrantee as to safety or
   accuracy of the results.  Use at your own risk.

Installation:

   For most systems, installing fsanalyze should consist simply of editing
   the Makefile and running make.  The Makefile is self-documenting (yeah,
   I know, I know!).  For convenience, I've included a number of different
   Makefiles that are configured for various systems.  Ultrix users should
   be able to use the Sun version with no changes.

   Note that for Microport System V/AT systems, HAVE_FSSTAT should be
   defined, since the is_ok(fs) macro defined in fsanalyze.h will not work.

   Where fsanalyze is installed doesn't really matter, but I would recommend
   placing it somewhere in the root filesystem, which is always mounted.  I
   typically run fsanalyze during my backup procedure, while my other
   filesystems are unmounted.

   Fsanalyze is not a setuid program, so the user must have read access to
   the file system to be analyzed.  I run it as root for this reason, but
   if you're paranoid, it would be better just run it in the same group
   as the the file systems (sys on my system).

Usage:
   fsanalyze [-flags] special [file [...]]

   If the optional file arguments are missing, the entire file system
   is analyzed.  If present, the specified files are analyzed and reported
   individually.

   [flags] include the following:
     b#  assume '#' bytes per logical block -- by default, this value
         is calculated automatically.  Supported, but not useful, for
         BSD file systems.
     c#  assume '#' sectors per disk cylinder -- by default,
         this value is determined by information in the superblock.
     d   display i-node numbers as they are examined.
     e   report file size inconsistencies - the inode numbers are reported
         for files where the file size and number of data blocks are
         inconsistent.
     g#  assume an inter-block gap of '#' sectors -- by
         default this information is taken from the superblock. Not
         useful, for BSD file systems.
     i   report double and triple indirection - the inode numbers are
         reported for files that contain double and/or triple indirection.
     o   overrides error checking on file system.  Use this flag if the
         file system you are analyzing is damaged.  Note that fsanalyze
         may give erroneous results if used on a damaged file system, but
         the file system itself will not be modified.
     v   Display current version number and patch level.

   Example:
     fsanalyze /dev/dsk/0s2	/* analyzes an entire file system */
     fsanalyze /dev/dsk/0s2 *	/* analyzes all files in the current
                                 * directory of the file system */

   Since fsanalyze uses the superblock info ON THE DISK, more accurate
   results will be returned fsanalyze is run on an unmounted, or read-only
   mounted file system.

   Since fsanalyze does its work the old fashioned way (brute-force), it
   must scan through the file system inode by inode.  It therefore takes
   a while to finish.  Be patient.

Bugs:
   Please report any bugs (and possible fixes) to me, so I can keep my
   source up-to-date.  I'm sure there are plenty of bugs, especially in the
   BSD-specific stuff.  Since I don't have access to anything but my little 
   Microport System V/AT system, it's hard for me to find portability bugs.

   Known Bugs include:
      1.  I don't trust the rotation delay statistics, especially for
          BSD file systems.  The numbers seem to be much too high to be
          believable.
