home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 October / usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso / misc / volume5 / fsanalyze4.1 / part01 / README < prev    next >
Text File  |  1989-02-03  |  7KB  |  132 lines
  1. FSANALYZE - File System Analyzer tool
  2. Version  : 4.1.1.2 - 88/11/30 15:53:38
  3.  
  4. Author   : Michael J. Young
  5. USmail   : Software Development Technologies, Inc.
  6.            375 Dutton Rd
  7.            Sudbury MA  01776
  8. UUCP     : harvard!sdti!mjy
  9. Internet : mjy@sdti.SDTI.COM
  10.  
  11.    =========================================================================
  12.    Note : This program has been placed in the public domain to permit
  13.    unrestricted distribution and use.  I have placed no copyright on it, but
  14.    I request that you keep me informed about any enhancements and bug fixes
  15.    you make so I can keep an up-to-date copy for further distribution.
  16.    =========================================================================
  17.  
  18.    This is a completely new version of fsanalyze which contains a number of
  19.    bug fixes, new features, and enhanced portability.  This version of
  20.    fsanalyze has been ported to the BSD fast file system, and run
  21.    successfully on a Sun.  It has also run successfully under Ultrix,
  22.    but some changes may be needed in the #include directives in
  23.    the file "fsanalyze.h".
  24.  
  25.    For a complete revision history, see the file called "Changes".  Other
  26.    useful information may be found in the file called "Info".
  27.  
  28. Introduction:
  29.    Fsanalyze is a simple tool that estimates file system fragmentation.  It
  30.    accomplishes this by scanning the data blocks for each i-node in the 
  31.    file system, looking for block numbers that are out of sequence.  In
  32.    effect, it is counting the number of disk seeks required to read the
  33.    entire file in sequence.  Fragmentation is then computed as the ratio
  34.    of actual "seeks" to the potential number of "seeks" if the file were
  35.    completely fragmented.
  36.  
  37.    Fsanalyze also provides a number of other useful statistics regarding the
  38.    file system usage, including the number (and identity) of files that are
  39.    very large, sparse files, and excessively large directories (i.e.,
  40.    directory files that require data block indirection, making filename
  41.    searches very inefficient).
  42.    
  43.    After the general file system statistics are displayed, fsanalyze lists
  44.    the 10 most fragmented i-nodes in the file system.  The 10 most
  45.    fragmented files are listed in decreasing order of fragmentation based on
  46.    the absolute number of fragments.  For example, a 100-block file that
  47.    contains 40 individual fragments is 39.39% fragmented (39 seeks / 99
  48.    potential seeks), but is listed before a 2-block file that contains 2
  49.    fragments (100% fragmented).  Thus, larger fragmented files (which have a
  50.    greater effect on file system performance) are listed before small files.
  51.  
  52.    In my estimation fsanalyze is completely safe, since it never writes to
  53.    the file system that it is analyzing and uses only the standard I/O
  54.    library to do its work.  It should be possible to run fsanalyze on a
  55.    write-protected file system, if you're worried.  If anything should go
  56.    wrong, the worst you will see is fseek() errors.  Be that as it may,
  57.    however, there is no express or implied warrantee as to safety or
  58.    accuracy of the results.  Use at your own risk.
  59.  
  60. Installation:
  61.  
  62.    For most systems, installing fsanalyze should consist simply of editing
  63.    the Makefile and running make.  The Makefile is self-documenting (yeah,
  64.    I know, I know!).  For convenience, I've included a number of different
  65.    Makefiles that are configured for various systems.  Ultrix users should
  66.    be able to use the Sun version with no changes.
  67.  
  68.    Note that for Microport System V/AT systems, HAVE_FSSTAT should be
  69.    defined, since the is_ok(fs) macro defined in fsanalyze.h will not work.
  70.  
  71.    Where fsanalyze is installed doesn't really matter, but I would recommend
  72.    placing it somewhere in the root filesystem, which is always mounted.  I
  73.    typically run fsanalyze during my backup procedure, while my other
  74.    filesystems are unmounted.
  75.  
  76.    Fsanalyze is not a setuid program, so the user must have read access to
  77.    the file system to be analyzed.  I run it as root for this reason, but
  78.    if you're paranoid, it would be better just run it in the same group
  79.    as the the file systems (sys on my system).
  80.  
  81. Usage:
  82.    fsanalyze [-flags] special [file [...]]
  83.  
  84.    If the optional file arguments are missing, the entire file system
  85.    is analyzed.  If present, the specified files are analyzed and reported
  86.    individually.
  87.  
  88.    [flags] include the following:
  89.      b#  assume '#' bytes per logical block -- by default, this value
  90.          is calculated automatically.  Supported, but not useful, for
  91.          BSD file systems.
  92.      c#  assume '#' sectors per disk cylinder -- by default,
  93.          this value is determined by information in the superblock.
  94.      d   display i-node numbers as they are examined.
  95.      e   report file size inconsistencies - the inode numbers are reported
  96.          for files where the file size and number of data blocks are
  97.          inconsistent.
  98.      g#  assume an inter-block gap of '#' sectors -- by
  99.          default this information is taken from the superblock. Not
  100.          useful, for BSD file systems.
  101.      i   report double and triple indirection - the inode numbers are
  102.          reported for files that contain double and/or triple indirection.
  103.      o   overrides error checking on file system.  Use this flag if the
  104.          file system you are analyzing is damaged.  Note that fsanalyze
  105.          may give erroneous results if used on a damaged file system, but
  106.          the file system itself will not be modified.
  107.      v   Display current version number and patch level.
  108.  
  109.    Example:
  110.      fsanalyze /dev/dsk/0s2    /* analyzes an entire file system */
  111.      fsanalyze /dev/dsk/0s2 *    /* analyzes all files in the current
  112.                                  * directory of the file system */
  113.  
  114.    Since fsanalyze uses the superblock info ON THE DISK, more accurate
  115.    results will be returned fsanalyze is run on an unmounted, or read-only
  116.    mounted file system.
  117.  
  118.    Since fsanalyze does its work the old fashioned way (brute-force), it
  119.    must scan through the file system inode by inode.  It therefore takes
  120.    a while to finish.  Be patient.
  121.  
  122. Bugs:
  123.    Please report any bugs (and possible fixes) to me, so I can keep my
  124.    source up-to-date.  I'm sure there are plenty of bugs, especially in the
  125.    BSD-specific stuff.  Since I don't have access to anything but my little 
  126.    Microport System V/AT system, it's hard for me to find portability bugs.
  127.  
  128.    Known Bugs include:
  129.       1.  I don't trust the rotation delay statistics, especially for
  130.           BSD file systems.  The numbers seem to be much too high to be
  131.           believable.
  132.