Browse Prior Art Database

Prevention Scheme for File Allocation Corruption

IP.com Disclosure Number: IPCOM000105474D
Original Publication Date: 1993-Aug-01
Included in the Prior Art Database: 2005-Mar-19
Document File: 4 page(s) / 93K

Publishing Venue

IBM

Related People

Barnes, CC: AUTHOR [+3]

Abstract

Disclosed is a method for ensuring file allocation integrity in a file system. The primary purpose is to detect and prevent inconsistencies in file allocation information between the logical and physical views of a file which result in file corruption. A secondary purpose is to capture system information closer to the offending events causing the inconsistencies, thereby facilitating quicker and more accurate resolution of root problems.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Prevention Scheme for File Allocation Corruption

      Disclosed is a method for ensuring file allocation integrity in
a file system.  The primary purpose is to detect and prevent
inconsistencies in file allocation information between the logical
and physical views of a file which result in file corruption.  A
secondary purpose is to capture system information closer to the
offending events causing the inconsistencies, thereby facilitating
quicker and more accurate resolution of root problems.

      Within a file system, the allocation of a file has a logical
and a physical image.  These images are managed by distinct
components within the file system.  When these images get out of
sync, the file becomes corrupted.

      A corrupted file in this context is one in which the permanent
record of physical block numbers (pbns) associated with the file is
incorrect.  This information is incorrect in that the pbns recorded
no longer belong to the file.  In most cases, the pbns have been
unallocated.  In some cases, the unallocated pbns have been assigned
to other files.  This corruption cannot be repaired.  The files can
only be erased.  The problem is due to keeping physical block
information in logical tables and relying on that information being
correct when committing files.

The solution is comprised of the following elements:

1.  Keep track of dynamic allocation information (pbns allocated and
    unallocated) on a file basis during a Logical Unit of Work (LUW)
    (Physical Allocation Manager).
2.  Verify the requested changes to a file's allocation record
    against what was tracked during the LUW and the permanent image
    (Physical File Manager).
3.  Prevent commit of changes unless all allocation information is
    accounted for (Commit Manager).

      The general processing flow for file manipulations is file
allocation or unallocation, alteration of file data to reflect
allocation changes, and commit of changes.  Commit of changes
includes updating the physical version of the file image and then
doing a commit request.  The solution fits into this normal flow to
trap requested anomalies concerning file...