home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / misc / volume2 / sys5-fs-analysis / README < prev   
Encoding:
Text File  |  1991-08-07  |  7.7 KB  |  163 lines
  1. FSANALYZE - System V File System Analyzer tool - v2.04, 7 Januaray 1988
  2.  
  3. Author   : Michael J. Young
  4. USmail   : Software Development Technologies, Inc.
  5.            375 Dutton Rd
  6.            Sudbury MA  01776
  7. UUCP     : {decvax|harvard|linus|mit-eddie}!necntc!necis!mrst!sdti!mjy
  8. Internet : mjy%sdti.uucp@harvard.harvard.edu
  9.  
  10.    =========================================================================
  11.    Note : This program has been placed in the public domain to permit
  12.    unrestricted distribution and use.  I have placed no copyright on it, but
  13.    I request that you keep me informed about any enhancements and bug fixes
  14.    you make so I can keep an up-to-date copy for further distribution.
  15.    =========================================================================
  16.  
  17.    Fsanalyze is a simple tool that estimates file system fragmentation.  It
  18.    accomplishes this by scanning the data blocks for each i-node in the 
  19.    file system, looking for block numbers that are out of sequence.  In
  20.    effect, it is counting the number of disk seeks required to read the
  21.    entire file in sequence.  Fragmentation is then computed as the ratio
  22.    of actual "seeks" to the potential number of "seeks" if the file were
  23.    completely fragmented.
  24.  
  25.    Fsanalyze also provides statistics regarding the number (and identity) of
  26.    files that are very large, and excessively large directories.
  27.    
  28.    Excessively large directories are directories that are over 5120 bytes
  29.    long (320 entries).  Directories larger than this require data block
  30.    indirection, making file searches very inefficient.
  31.  
  32.    After the general file system statistics are displayed, fsanalyze lists
  33.    the 10 most fragmented i-nodes in the file system.  
  34.    The 10 most fragmented files are listed in decreasing order of 
  35.    fragmentation based on the absolute number of fragments.  For example,
  36.    a 100-block file that contains 40 individual fragments is 39.39%
  37.    fragmented (39 seeks / 99 potential seeks), but is listed before
  38.    a 2-block file that contains 2 fragments (100% fragmented).  Thus, larger
  39.    fragmented files (which have a greater effect on file system performance)
  40.    are listed before small files.
  41.  
  42. Revision History:
  43.  
  44.    Version 2.0 is a major rewrite of fsanalyze that adds the following new
  45.    features:
  46.        - The ability to analyze individual files
  47.        - Display of the 10 most fragmented files in a file system
  48.        - Enhanced error checking on the file system argument
  49.  
  50.    Version 2.01 contains a minor modification in which fsanalyze executes
  51.    /etc/fsstat to determine the health of the file system before analyzing
  52.    it.
  53.  
  54.    Version 2.02 contains a minor modification to print out a warning message
  55.    if the file system being analyzed is currently mounted.
  56.  
  57.    Version 2.03 contains a fix for a minor bug in which the size of the
  58.    volume data block size would be printed out incorrectly for large
  59.    file systems.
  60.  
  61.    Version 2.04 incorporates the library function l3tol to access inode
  62.    block numbers.
  63.  
  64. Installation:
  65.  
  66.    This program is so simple that I didn't bother to create a Makefile.  To
  67.    build fsanalyze the steps are:
  68.       cc -O -o fsanalyze fsanalyze.c
  69.       mv fsanalyze /bin
  70.    Where fsanalyze is installed doesn't really matter, but I would recommend
  71.    placing it somewhere in the root filesystem, which is always mounted.  I
  72.    typically run fsanalyze during my backup procedure, while my other
  73.    filesystems are unmounted.
  74.  
  75. Usage:
  76.    fsanalyze [-flags] special [file [...]]
  77.  
  78.    If the optional filename arguments are missing, the entire file system
  79.    is analyzed.  If present, the specified files are analyzed and reported
  80.    individually.
  81.  
  82.    [flags] include the following:
  83.      d   display i-node numbers as they are examined
  84.      e   report file size inconsistencies - the inode numbers are reported
  85.          for files where the file size and number of data blocks are
  86.          inconsistent.
  87.      i   report double and triple indirection - the inode numbers are
  88.          reported for files that contain double and/or triple indirection.
  89.      o   overrides error checking on file system.  Use this flag if the
  90.          file system you are analyzing is damaged.  Note that fsanalyze
  91.          may give erroneous results if used on a damaged file system, but
  92.          the file system itself will not be affected.
  93.  
  94.    Example:
  95.      fsanalyze /dev/dsk/0s2    /* analyzes an entire file system */
  96.      fsanalyze /dev/dsk/0s2 *    /* analyzes all files in the current
  97.                                  * directory of the file system */
  98.  
  99.    Since fsanalyze uses the superblock info ON THE DISK, more accurate
  100.    results will be returned fsanalyze is run on an unmounted, or read-only
  101.    mounted file system immediately after a sync(2).
  102.  
  103.    Note that fsanalyze will work with 512- or 1024-byte filesystems.  In
  104.    filesystems with 1024-byte blocking-factors, free-blocks, etc., are
  105.    reported as 1024-byte blocks (unlike df(1) and du(1)).  Therefore, the total
  106.    number of free blocks in your file system will be reported as half the
  107.    value reported by df(1).  I prefer it this way.  If you want it the
  108.    other way, it requires a simple change to print_report().
  109.  
  110.    Since fsanalyze does its work the old fashioned way (brute-force), it
  111.    must scan through the file system inode by inode.  It therefore takes
  112.    about as long as fsck to do its work.  Be patient.
  113.  
  114. Bugs:
  115.    Please report any bugs (and possible fixes) to me, so I can keep my
  116.    source up-to-date.  I would also like to make fsanalyze work on other
  117.    unix systems, but I don't have access to anything but my little 
  118.    uport.  If you can help me port it to BSD or anything else, I would
  119.    appreciate it.
  120.  
  121. Porting fsanalyze to other systems:
  122.    Fsanalyze takes its information on the structure of the file system
  123.    from /usr/include/sys/filsys.h and /usr/include/sys/ino.h.  As long
  124.    as these files (or equivalent) are present on your system, porting
  125.    should be straightforward.  When looking for the equivalent of these
  126.    files on your system, be sure to get the disk-based versions, rather
  127.    than the in-memory structures -- they are different.  In System V
  128.    derivatives, these structures should be documented as fs(4 or 5) and
  129.    inode(4 or 5), on BSD systems and V7 systems as filsys(5), and on
  130.    XENIX 3.0 and 5.0 as filesystem(F).
  131.  
  132.    Fsanalyze uses fsstat(1M) to determine file system integrity.  I don't
  133.    think this program is available in other versions of Unix.  If your
  134.    system doesn't have it (or anything like it), you will have to rewrite
  135.    check_fs().  The kinds of things to check when testing for file system
  136.    integrity include:
  137.     1.  Make sure the device is block structured.
  138.     2.  Determine whether or not the device is mounted.
  139.     3.  Check s_state in the filsys structure to see if it is in a
  140.         known state.
  141.     4.  Anying else you can think of.
  142.    I used fsstat because it seems to be more robust than anything I
  143.    could come up with.  It also appears to use undocumented information
  144.    to determine file system status.
  145.  
  146.    fsstat(1M) returns 0 if the file system is ok, 1 if it needs to be
  147.    checked, 2 if it is mounted, and 3 for other errors.  Unfortunately,
  148.    the exit status appears to be byte-swapped when fsanalyze gets it.
  149.    I'm not sure if this is a bug in system(3S), or my use of it, but
  150.    be careful when porting to your system.
  151.   
  152.    I attempted to use types defined in /usr/include/sys/types.h wherever
  153.    possible to ensure portability.  I don't think I made any assumptions
  154.    about sizeof(int) == sizeof(long) == sizeof(char *), so there should
  155.    be no problems there.
  156.  
  157.    Please try to make changes to the source using #defines and #ifdefs
  158.    wherever possible, and please email me the changes you make along with
  159.    a description of the system you ported it to (and problems encountered),
  160.    so I can merge all the changes into a single copy.
  161.  
  162.    Thanks and good luck!
  163.