Abstract:
Data structure errors, or corruptions, identified during, e.g., normal computing device system processing, file system processing or user access processing, are verified prior to the file system identifying the error for offline correction or notifying the user or system administrator a data structure error exists. Identified data structure corruptions are verified while the file system volumes are maintained online and otherwise accessible to other processing tasks and user access. Verified data structure corruptions are logged for further corrective processing. Data structure corruptions that cannot be verified, i.e., false positives, are not further processed and are not identified to file system administrators or users as corruptions, freeing the file system to concentrate on normal processing and true, verifiable errors.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application is related to commonly assigned, co-pending U.S. patent application Ser. No. ______, (docket no. MS330826.01), entitled “File System Resiliency Management”, and commonly assigned, co-pending U.S. patent application Ser. No. ______, (docket no. MS330827.01) entitled “Proactive Error Scan And Isolated Error Correction”, each of which is filed herewith and incorporated herein by reference in their entirety. 
     
    
     BACKGROUND 
       [0002]    File systems utilize data structures, also referred to as the file system on-disk format, to maintain and organize data on non-volatile, i.e., persistent, storage, e.g., a volume, disk, hard drive, etc. File systems access and interpret these data structures to store and retrieve data for users and applications, or procedures or computer programs, e.g., when executing software instructions or computer code. 
         [0003]    When the file system encounters an error, i.e., a corruption, while trying to access and/or interpret the data structures the file system notes that there is an error and flags the particular storage volume, also referred to herein as volume, as corrupt. Even if the file system attempts to isolate and correct a reported error online, i.e., a self-healing system, some number of encountered corruptions cannot be resolved unless the volume is taken offline. However, while the volume is being processed offline to correct for errors the data and information stored thereon in its data structures is unavailable to any user or other application. These offline periods can be relatively lengthy, further degrading system availability and user satisfaction. 
         [0004]    Moreover, when a file system believes it has encountered a corruption while trying to access a volume&#39;s data structures, there may be no real existing data structure corruption. In these cases, the error can generally be attributed to other events, e.g., transient errors in the system&#39;s volatile memory, transient errors in the system&#39;s non-volatile storage, bugs in the file system, etc. However, with existing technology file systems cannot discern between real corruption instances requiring offline processing to remedy and false positive instances when a data structure error is perceived but does not in fact exist. 
         [0005]    Thus, it is desirable to verify perceived corruptions prior to taking a volume offline in order to significantly reduce the amount of time any of the file system volumes are offline, and thus unavailable for user and other application access. It would also be desirable to limit the error instances reported to file system administrators and users to those involving verified, i.e., true or real, corruptions. 
       SUMMARY 
       [0006]    This summary is provided to introduce a selection of concepts in a simplified form which are further described below in the Detailed Description. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. 
         [0007]    Embodiments discussed herein include systems and methodology for the verification of prior identified volume corruptions on volumes in a file system to minimize processing efforts expended in attempting to remedy identified corruptions and to diminish volume unavailability. 
         [0008]    In embodiments, read-only snapshots of volumes that have prior identified corruptions thereon are generated. In embodiments, the snapshots are then processed for corruption verification, while the corresponding volume remains online and accessible. In embodiments, and utilizing the volume snapshots, prior identified corruptions are either verified as true, existing corruptions that the file system can thereafter attempt to remedy, or are determined to be false positives. In an aspect of these embodiments false positives are prior identified corruptions that are not in fact volume corruptions that the file system will expend time and effort attempting to remedy. 
         [0009]    In embodiments corruptions are categorized into one of a predefined, limited group of corruption categories. In aspects of these embodiments corruption categorization can be utilized for, e.g., file system processing analysis, corruption verification, as an aid in subsequent corruption correction, etc. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0010]    These and other features will now be described with reference to the drawings of certain embodiments and examples which are intended to illustrate and not to limit, and in which: 
           [0011]      FIG. 1  depicts an embodiment file system with a spot corruption verifier component. 
           [0012]      FIGS. 2A-2B  illustrate an embodiment logic flow for online spot verification of identified corruptions in file system data structures. 
           [0013]      FIG. 3  illustrates an embodiment logic flow for file system manager processing in conjunction with online spot verification. 
           [0014]      FIG. 4  depicts an exemplary error log entry. 
           [0015]      FIG. 5  is a block diagram of an exemplary basic computing device with the capability to process software, i.e., program code, or instructions. 
       
    
    
     DETAILED DESCRIPTION 
       [0016]    In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of embodiments described herein. It will be apparent however to one skilled in the art that the embodiments may be practiced without these specific details. In other instances well-known structures and devices are either simply referenced or shown in block diagram form in order to avoid unnecessary obscuration. Any and all titles used throughout are for ease of explanation only and are not for any limiting use. 
         [0017]      FIG. 1  depicts an embodiment file system  100  with a file system manager  110 . In an embodiment the file system manager  110  is a software application task for managing the file system  100  to assist in ensuring proper processing and operation. 
         [0018]    In an embodiment the file system  100  also has one or more volumes  130  that store data in data structures for use by processing applications, tasks, programs, routines, etc., collectively referred to as processing applications  160  herein, and users  180 . In an embodiment one volume  130  is a system volume  130 . 
         [0019]    In embodiments processing applications  160  can be part of the file system  100  and/or separate from the file system  100 . 
         [0020]    In an embodiment, when the file system  100  encounters an unexpected condition while accessing a data structure on a volume  130 , the unexpected condition, which becomes a flagged data structure error, is categorized, the data structure(s) involved are identified, and an entry identifying the flagged data structure error is generated in an error verification log  140  for the volume  130  as further discussed below. 
         [0021]    An embodiment file system  100  includes a spot corruption verifier component  120 . In an embodiment the spot corruption verifier  120  is a software application task that is executed by the file system  100  when one or more errors, or corruptions, have been flagged, or otherwise identified, on one or more volumes  130  of the file system. In an embodiment the spot corruption verifier  120  is initiated to process by the file system manager  110 . 
         [0022]    In an embodiment the spot corruption verifier  120  executes, or otherwise processes, while all file system volumes  130  remain online. 
         [0023]    In an embodiment the spot corruption verifier  120  attempts to verify prior flagged, i.e., prior identified, data structure corruptions. In an aspect of this embodiment the spot corruption verifier  120  does not look for, or otherwise attempt to discover or verify, other possible corruptions that are not already identified when the spot corruption verifier  120  processes, i.e., runs. 
         [0024]    In an embodiment the spot corruption verifier  120  has the capability to perform actions that are designed to verify, i.e., analyze, prior identified corruptions on the volumes  140  of the file system  100  to determine whether the prior identified corruptions do in fact exist. 
         [0025]    In an embodiment the spot corruption verifier  120  notifies the file system  100  when it deems, or otherwise determines, a flagged corruption to be a false positive, i.e., when the spot corruption verifier  120  concludes that a prior identified data structure error does not in fact exist. In an aspect of this embodiment the spot corruption verifier  120  notifies the file system manager  110  when it deems a flagged corruption to be a false positive. 
         [0026]    In an embodiment the spot corruption verifier  120  also notifies the file system  100  when it deems, or otherwise determines, a flagged corruption to be a true corruption, i.e., when the spot corruption verifier  120  concludes that a prior identified data structure error is a true, existing error. In an aspect of this embodiment the spot corruption verifier  120  notifies the file system manager  110  when it deems a flagged corruption to be a true corruption. 
         [0027]    In an embodiment, when the spot corruption verifier  120  verifies a flagged data structure error, a corruption entry  195  is generated for the now verified, i.e., true, corruption in an error correction log  190  for the volume  130  as further discussed below. 
         [0028]    In an embodiment the file system  100  notifies the file system administrator(s)  180  and/or file system user(s)  180 , also collectively referred to herein as user  180 , when it concludes that a prior flagged data structure error is a true, existing error. In an aspect of this embodiment the file system manager  110  notifies a user  180  when a prior identified data structure error is determined to be a true corruption. In an alternative aspect of this embodiment the spot corruption verifier  120  notifies a user  180  when a prior identified data structure error is determined to be a true corruption. 
         [0029]    In an embodiment each volume  130  of a file system  100  has an associated error verification log  140 , e.g., a $Verify file, also referred to as a volume verification log  140 , where flagged, i.e., reported, data structure errors for the respective volume  130  are recorded, or otherwise indicated, via, e.g., verification entries  145  therein. In other embodiments flagged data structure errors, also referred to herein as volume errors, are reported by the use of other mechanisms, e.g., a single verification log  140  of verification entries  145  is utilized to report all volume errors for all volumes  130  of the file system  100 , error tables are written to identify volume errors, etc. 
         [0030]    In an embodiment a volume&#39;s verification log  140  is maintained on the respective volume  130 . In an alternative embodiment volume verification logs  140  are maintained separate from their respective volumes  130 . 
         [0031]    In an embodiment each volume  130  of a file system  100  has an associated error correction log, e.g., $Corrupt file,  190 , also referred to as a volume corruption log  190 , volume corrupt log  190  or corrupt log  190 , where verified data structure errors for the respective volume  130  are recorded, or otherwise indicated, via, e.g., corruption entries  195 . In other embodiments verified data structure errors are reported by the use of other mechanisms, e.g., a single error correction log  190  of corruption entries  195  is utilized to report all verified volume errors for all volumes  130  of the file system  100 , error tables are written to identify verified volume errors, etc. 
         [0032]    In an embodiment a volume&#39;s error correction log  190  is maintained on the respective volume  130 . In an alternative embodiment volume error correction logs  190  are maintained separate from their respective volumes  130 . 
         [0033]    In an embodiment each volume  130  has an associated dirty bit, or flag,  150  that, when set, indicates that the volume  130  has at least one verified, i.e., true, existing, corruption on it. 
         [0034]    In an embodiment the file system  100  has an event log  170  where events, e.g., verified error corruptions, etc., are reported via, e.g., event log entries  175 . In an embodiment event log entries  175  are utilized for communication between the spot corruption verifier  120  and the file system manager  110 . In an embodiment event log entries  175  are utilized by the file system  100  to inform a user  180  of verified corruptions. In an embodiment event log entries  175  are utilized by the file system  100  for file system  100  analysis, maintenance, error detection and correction, etc. In embodiments event log entries  175  are used for additional, other, additional and/or other combinations of tasks. 
         [0035]      FIGS. 2A and 2B  illustrate an embodiment logic flow for effectively and efficiently verifying volume errors while the respective volume  130  remains online and otherwise available. While the following discussion is made with respect to systems portrayed herein the operations described may be implemented in other systems. The operations described herein are not limited to the order shown. Additionally, in other alternative embodiments more or fewer operations may be performed. Further, the operations depicted may be performed by an embodiment spot corruption verifier  120  or by an embodiment spot corruption verifier  120  in combination with one or more other system entities, components and/or applications, such as, but not limited to, a file system manager  110 . 
         [0036]    Referring to  FIG. 2A  in an embodiment a spot corruption verifier  120  queries the file system manager for an identification of the volumes on the system that have verification entries in their associated error verification log  202 . In alternative embodiments the spot corruption verifier  120  identifies currently existing system volumes with flagged data structure errors via other mechanisms, e.g., by the use of tables, bit streams, etc., of volume flags identifying volumes with currently flagged data structure errors, etc. 
         [0037]    In an embodiment the spot corruption verifier identifies a volume with verification entries in its associated error verification log  204 . In an embodiment the spot corruption verifier takes, or otherwise generates, a snapshot of the identified volume  206 . In an embodiment the snapshot of the identified volume includes a snapshot of the volume&#39;s error verification log, e.g., $Verify file,  206 . In an alternative embodiment the spot corruption verifier takes, or otherwise generates, a snapshot of the error verification log, e.g., $Verify, for the identified volume  208 . In this alternative embodiment the generation of the snapshot of the error verification log  140  is synchronized with the generation of the snapshot of the respective identified volume  130  in order that the snapshots of the volume  130  and its error verification log  140  are consistent. 
         [0038]    In an embodiment the snapshot(s) of the identified volume  130  and the identified volume&#39;s error verification log  140  are read-only. 
         [0039]    In an embodiment the spot corruption verifier identifies a verification entry in the snapshot version of the error verification log  210 ; i.e., identifies a verification entry for a flagged, i.e., prior identified, data structure corruption to be processed, or verified. In an embodiment and using the identified verification entry, the spot corruption verifier analyzes 
         [0040]    In an embodiment corruptions identified with a verification entry  145  in a volume&#39;s error verification log  140  have been categorized, as further discussed below. In an embodiment the corruption categorization is utilized by the spot corruption verifier  120  as the spot corruption verifier  120  attempts to verify the corruption for the current identified verification entry  145 . 
         [0041]    At decision block  214  a determination is made as to whether or not the data structure corruption identified in the current verification entry being processed is verified as a true data structure corruption. If no, the verification entry being processed identifies a false positive corruption  216 ; i.e., it identifies a data structure corruption that cannot be verified and therefore is deemed as not representing a true data structure corruption the file system will attempt to remedy. In an embodiment the spot corruption verifier informs the file system manager that there is no corruption for the currently processed verification entry  218 . In embodiments various mechanisms are utilized to inform the file system manager of a false positive for a verification entry, e.g., a flag, a table entry, a message, an interrupt, etc. 
         [0042]    In an embodiment at decision block  222  a determination is made as to whether or not there are any more verification entries to process in the snapshot of the current error verification log being processed. If yes, in an embodiment the spot corruption verifier identifies another verification entry in the snapshot error verification log currently being processed for a flagged data structure corruption to be verified  210 . 
         [0043]    If, however, at decision block  222  it is determined that there are no more verification entries to process in the snapshot of the error verification log currently being processed then in an embodiment the spot corruption verifier deletes the snapshot of the volume for which it is has currently been processing flagged data corruptions  224 . In an embodiment the deletion of the snapshot of a volume also causes the deletion of the snapshot of the volume&#39;s error verification log that is maintained on the volume. In an alternative embodiment, where the volumes&#39; error verification logs are maintained separately from their respective volumes, the spot corruption verifier deletes the snapshot of the error verification log that it has currently been processing  226 . 
         [0044]    In an embodiment at decision block  228  a determination is made as to whether there are any more volumes reported by the file system manager, or otherwise identified, as currently having verification entries in their associated error verification log. If yes, in an embodiment the spot corruption verifier identifies another volume of the file system with verification entries in its associated error verification log to now be processed  204 . 
         [0045]    If, however, at decision block  228  there are no more volumes currently reported by the file system manager, or otherwise identified, as having verification entries in their associated error verification logs then in an embodiment the spot corruption verifier processing ends  230 . 
         [0046]    Referring again to decision block  214 , if the spot corruption verifier verifies a flagged data structure corruption with an associated verification entry in the snapshot of the error verification log currently being processed then in an embodiment, and referring to  FIG. 2B , the reported volume corruption is verified as a true, existing corruption  232 . 
         [0047]    In an embodiment the spot corruption verifier informs the file system manager that there is a verified volume corruption for the currently processed error verification log entry  234 . In embodiments various mechanisms are utilized to inform the file system manager of the verified volume corruption for the error verification log entry currently being processed, e.g., a flag; a table entry, a message; an interrupt; etc. 
         [0048]    In an embodiment, upon being notified of a verified volume corruption by the spot corruption verifier  120 , the file system manager  110  generates an event log entry  175  that identifies the verified, existing volume corruption, as further discussed below with reference to  FIG. 3 . In an alternative embodiment, the spot corruption verifier generates an event log entry that identifies the verified, existing volume corruption. 
         [0049]    In an embodiment the event log  170  and its entries  175  can be accessed by a user  180  to determine what has occurred within the file system  100 , e.g., to determine a verified volume corruption exists. In an alternative embodiment an event log entry  175  identifying a verified volume corruption is used by the file system manager  110  to report a message, e.g., via a pop-up text block on a computing device screen, to a user  180  that informs of the verified volume corruption. 
         [0050]    In an embodiment an event log entry identifying a verified volume corruption provides an indication of the file system&#39;s determination of the severity of the verified volume corruption. In an embodiment a reported message that informs of the verified volume corruption provides an indication of the file system&#39;s determination of the severity of the verified volume corruption. As noted, the indicated severity of the verified volume corruption can be used by a user  180  to assist in determining when action to attempt to remedy the corruption can, or ought, to be commenced. 
         [0051]    In an embodiment the spot corruption verifier sets a volume dirty bit, or volume flag, to indicate that the volume whose snapshot is currently being processed has at least one corruption  236 . In an alternative embodiment the file system manager  110  of the file system  100  sets the appropriate volume dirty bit, or volume flag,  150  when it is informed by the spot corruption verifier  120  that the volume  130  has at least one corruption. 
         [0052]    In an embodiment, and referring again to  FIG. 2A , at decision block  222  a determination is made as to whether there are any more entries to process in the snapshot of the current error verification log being processed. 
         [0053]      FIG. 3  illustrates an embodiment logic flow for a file system manager  110  to process in conjunction with spot corruption verification. While the following discussion is made with respect to systems portrayed herein the operations described may be implemented in other systems. The operations described herein are not limited to the order shown. Additionally, in other alternative embodiments more or fewer operations may be performed. Further, the operations depicted may be performed by an embodiment file system manager  110  or by an embodiment file system manager  110  in combination with one or more other system entities, components and/or applications. 
         [0054]    In an embodiment the file system manager  110  is processing and, at some point, a corruption is encountered on a volume of the file system  305 . In an embodiment the encountered corruption is categorized  310 , as further discussed with reference to  FIG. 4  below, and the corruption is logged  310 , i.e., a verification entry  145  for the corruption is generated in the affected volume&#39;s error verification log  140 . In an embodiment the file system manager  110  initiates, i.e., calls or activates, an embodiment spot corruption verifier  120  to process. 
         [0055]    In an embodiment at decision block  315  the file system manager determines whether the spot corruption verifier has verified a prior identified corruption as a true, existing corruption, or whether the spot corruption verifier has determined the prior identified corruption is a false positive. If the spot corruption verifier has determined that a prior identified corruption is a false positive, then in an embodiment the file system manager deletes the appropriate verification entry identifying the false positive corruption from the volume&#39;s error verification log  320 . 
         [0056]    If the spot corruption verifier has determined that a prior identified corruption is a true, existing corruption, i.e., a verified corruption, then in an embodiment the file system manager deletes the appropriate verification entry identifying the verified corruption from the volume&#39;s error verification log  325  and generates a respective entry for the verified corruption in the volume&#39;s error correction log  330 . 
         [0057]    In an embodiment, upon being notified of a verified volume corruption by the spot corruption verifier, the file system manager generates an event log entry that identifies the verified, existing volume corruption  335 . In an alternative embodiment, the spot corruption verifier  120  generates an event log entry  175  that identifies the verified, existing volume corruption. 
         [0058]    In an embodiment the event log  170  and its entries  175  can be accessed by a user  180  to determine what has occurred within the file system  100 , e.g., to determine a verified volume corruption exists. In an alternative embodiment an event log entry  175  identifying a verified volume corruption is used by the file system manager  110  to report a message, e.g., via a pop-up text block on a computing device screen, to a user  180  that informs of the verified volume corruption. 
         [0059]    In an embodiment an event log entry  175  identifying a verified volume corruption provides an indication of the file system&#39;s determination of the severity of the verified volume corruption. In an embodiment a reported message that informs of the verified volume corruption provides an indication of the file system&#39;s determination of the severity of the verified volume corruption. As noted, the indicated severity of the verified volume corruption can be used by a user  180  to assist in determining when an attempt to remedy the corruption can, or ought, to be commenced. 
         [0060]    In an embodiment at decision block  340  a determination is made as to whether current spot corruption verification processing has ended. If no, in an embodiment processing returns to decision block  315  where a determination is made as to whether the spot corruption verifier has verified a prior identified corruption as a true, existing corruption, or whether the spot corruption verifier has determined a prior identified corruption is a false positive. 
         [0061]    If at decision block  340  current spot corruption verification processing has ended then in an embodiment the file system manager  110  continues processing. 
         [0062]    As previously discussed, in an embodiment each volume  130  of a file system  100  has an associated error verification log  140  where flagged, i.e., reported, data structure errors for the respective volume  130  are recorded, or otherwise indicated, via, e.g., verification entries  145  therein. In an embodiment each volume  130  of a file system  100  also has an associated error correction log  190  where verified data structure errors for the respective volume  130  are recorded, or otherwise indicated, via, e.g., corruption entries  195 . An embodiment verification entry and embodiment corruption entry  400 , also referred to herein collectively as an error log entry  400 , is depicted in  FIG. 4 . 
         [0063]    In an embodiment each flagged data structure error is categorized at the time it is initially discovered and this categorization is included in a corruption type field  420  for an error log entry  400 . Thus, in an embodiment, when the file system  100  encounters an unexpected condition while accessing a data structure on a volume  130 , the unexpected condition, which becomes a flagged data structure error, is categorized, the data structure(s) involved are identified, and a verification entry  145  is generated in the proper volume&#39;s error verification log  140 . Thereafter, in an embodiment, when the spot corruption verifier  120  verifies a flagged data structure error, a corruption entry  195  is generated for the now verified data structure error in the proper volume&#39;s error correction log  190 . In an aspect of this embodiment, the generated corruption entry  195  is the corresponding verification entry  145  for the corruption that is now stored in the proper volume&#39;s error correction log  190 . 
         [0064]    In an embodiment an entry for the corruption type field  420  can be modified as necessary by the spot corruption verifier  120  when the spot corruption verifier  120  processes the volume corruption record  400  in the snapshot version of a volume&#39;s error verification log  140 . 
         [0065]    In an embodiment a set of categories  460  are identified to be utilized to categorize, or otherwise label, any particular volume corruption. In an embodiment there are a finite number of categories in the set of categories  460  to help promote efficient and meaningful processing thereof. For example, in an embodiment the category of a flagged data structure corruption is useful for generalizing and simplifying the verification processing of the respective data structure corruption. As another example, in an embodiment the category of a verified data structure corruption is useful for subsequent processing of any attempt to remedy the corruption. 
         [0066]    In an embodiment the set of categories  460  includes a general corruption category  402 . In an embodiment a general corruption category  402  indicates that some type of corruption was noticed and signifies that an inspection of the entire volume  130  for errors is warranted. 
         [0067]    In an embodiment an orphan child category  404  is included in the set of categories  460 . In an embodiment file system  100  a collection of one or more files is stored on each volume  130 . In an embodiment each file stored on a volume  130  has one or more records and each record consists of one or more segments. In an embodiment each segment consists of one or more fields that each contain data. In an embodiment a file record segment is the smallest element that can be retrieved from a volume  130 . In an embodiment each file record consists of a root, or base, parent, etc., segment. In an embodiment each file record can also contain one or more dependent, i.e., child segments. In an embodiment an orphan child category  404  indicates that an in-use child file record segment was located, i.e., there is an existing dependent file record segment that is in use and contains viable data, but that its base, or root, file record segment is either not in use or does not list the child file record as a child. 
         [0068]    In an embodiment a bad cluster category  406  is included in the set of categories  460 . In embodiment file systems  100  a cluster is the unit of disk space allocation for volume files. To reduce overhead in the management of file system volumes  130 , an embodiment file system  100  does not allocate individual disk sectors, but rather, contiguous groups of sectors, called clusters. In an embodiment a cluster is the smallest logical amount of disk space that can be allocated for a file on a volume  130 . In an embodiment a bad cluster category  406  indicates that a faulty sector was identified while accessing a cluster of non-resident stream data. 
         [0069]    In an embodiment stream data is user data. In an embodiment stream data is stored directly in a file record. In an embodiment non-resident stream data is that user data that is stored in their own clusters rather than directly in a file record. In an embodiment a bad cluster category  406  indicates that it is a user data cluster, where non-resident stream data is stored, that has a corruption. 
         [0070]    In an embodiment a bad free cluster category  408  is included in the set of categories  460 . In an embodiment a bad free cluster category  408  indicates that a faulty cluster was noticed during the access of a free, i.e., as yet, unused, cluster on the volume  130 . 
         [0071]    In an embodiment a crosslink corruption category  412  is included in the set of categories  460 . In an embodiment a crosslink corruption category  412  indicates that two different extents, e.g., two different volume files, were found to be using logical overlapping clusters, i.e., are using the same or a same portion of the volume&#39;s disk space. 
         [0072]    In an embodiment a security descriptor corruption category  414  is included in the set of categories  460 . In an embodiment a security descriptor corruption category  414  indicates that some type of corruption was noticed in the security descriptor stream. In an embodiment a security descriptor stream for a file on a volume  130  is a set of one or more security attributes, e.g., authorization access rules, associated with the file. 
         [0073]    In an embodiment an invalid security identification, or id, category  416  is included in the set of categories  460 . In an embodiment an invalid security id category  416  indicates that one or more file records were found to have non-zero security IDs that are not properly registered in a security ID index. 
         [0074]    In an embodiment an index attribute corruption category  418  is included in the set of categories  460 . In an embodiment file system  100  an index is one or more data structures that are utilized to improve the speed of data, i.e., object, retrievals from the file system volumes  130 . In an embodiment an index attribute defines, or otherwise describes, an aspect of the file that the index supports. In an embodiment the index attribute corruption category  418  indicates that a corruption was found in an index attribute which may necessitate the deletion of all attributes related to the respective index. 
         [0075]    In an embodiment an index entry corruption category  422  is included in the set of categories  460 . In an embodiment an index contains the name of a file and points to the named file on a file system volume  130 . In an embodiment the index entry corruption category  422  indicates that there is some type of corruption in the indicated index entry itself. 
         [0076]    In an embodiment an index subtree corruption category  424  is included in the set of categories  460 . In an embodiment an index subtree corruption category  424  indicates that a subtree index entry refers to a non-existent object. 
         [0077]    In an embodiment an index offset corruption category  426  is included in the set of categories  460 . In an embodiment an index offset corruption category  426  indicates that an index entry is corrupt. In an aspect of this embodiment an index offset corruption category  426  can further indicate that every subsequent index entry in the same index block is potentially corrupt. 
         [0078]    In an embodiment an index order corruption category  428  is included in the set of categories  460 . In an embodiment an index order corruption category  428  indicates that an index contains entries that are out of order. 
         [0079]    In an embodiment an index connect corruption category  432  is included in the set of categories  460 . In an embodiment the index connect corruption category  432  indicates that an index entry refers to a non-existent object, i.e., there appears to be a valid index entry yet it fails to refer to any object. In an embodiment an index connect corruption category  432  indicates that one or more objects ought to be inserted into an index, possibly as a result of, e.g., the recovery of a corrupted index. 
         [0080]    In an embodiment a directory cycle corruption category  434  is included in the set of categories  460 . In an embodiment file system  100  directories are used to associate files with their respective filenames. In an embodiment a directory cycle corruption category  434  indicates that a directory cycle was found in the file system namespace, i.e., there is an entry in a directory for a volume  130  that identifies an ancestor, i.e., parent, of the directory. 
         [0081]    In an embodiment a cluster allocation corruption category  436  is included in the set of categories  460 . In an embodiment a cluster allocation corruption category  436  indicates that clusters were found to be in use on the volume  130  but are marked as free, i.e., not in use, for the respective volume. 
         [0082]    In an embodiment the format of a volume corruption record  400  is relatively compact in order to conserve space but it is also designed for ease of parsing so that the applications that work with its contents, e.g., an embodiment spot corruption verifier  120 , can interpret the record&#39;s contents without requiring unnecessarily complicated deserialization operations. In an embodiment the format of a volume corruption record  400  is also flexible to accommodate, e.g., future extensions with minimal data and/or application redesign. 
         [0083]    An embodiment volume corruption record  400  is of variable length, binary format. In an embodiment the fields of the volume corruption record  400  are encoded. In an aspect of this embodiment the fields of the volume corruption record  400  are encoded utilizing little endian byte ordering. 
         [0084]    An embodiment volume corruption record  400  has a header field  410  which includes an instance tag that uniquely identifies the particular volume corruption record  400 . In an embodiment the header field  410  of a volume corruption record  400  also includes the length, e.g., in bytes, of the volume corruption record  400 . 
         [0085]    An embodiment volume corruption record  400  includes a call stack identification field  430 . In an embodiment the call stack identification field  430  contains a data structure entry that describes the kernel call stack at the point when the respective volume corruption was detected. In an embodiment the call stack identification field  430  contains a file id that uniquely identifies the source file that was executing when the respective volume corruption was detected. In an embodiment the call stack identification field  430  contains an identification of the source line number that was executing when the respective volume corruption was detected. In an embodiment the call stack identification field  430  contains a unique integer for identifying the location in the code base that was executing when the respective volume corruption was detected. 
         [0086]    An embodiment volume corruption record  400  includes a binary sample corruption field  440 . In an embodiment the binary sample corruption field  440  contains a data structure entry that has an arbitrary sample of binary data illustrative of the respective volume corruption. 
       Computing Device System Configuration 
       [0087]      FIG. 5  is a block diagram that illustrates an exemplary computing device system  500  upon which an embodiment can be implemented. Examples of computing device systems, or computing devices,  500  include, but are not limited to, servers, server systems, computers, e.g., desktop computers, computer laptops, also referred to herein as laptops, notebooks, etc.; etc. 
         [0088]    The embodiment computing device system  500  includes a bus  505  or other mechanism for communicating information, and a processing unit  510 , also referred to herein as a processor  510 , coupled with the bus  505  for processing information. The computing device system  500  also includes system memory  515 , which may be volatile or dynamic, such as random access memory (RAM), non-volatile or static, such as read-only memory (ROM) or flash memory, or some combination of the two. The system memory  515  is coupled to the bus  505  for storing information and instructions to be executed by the processing unit  510 , and may also be used for storing temporary variables or other intermediate information during the execution of instructions by the processor  510 . The system memory  515  often contains an operating system and one or more programs, or applications, and/or software code, and may also include program data. 
         [0089]    In an embodiment a storage device  520 , such as a magnetic or optical disk solid state drive, flash drive, etc., is also coupled to the bus  505  for storing information, including program code of instructions and/or data. In the embodiment computing device system  500  the storage device  520  is computer readable storage, or machine readable storage,  520 . 
         [0090]    Embodiment computing device systems  500  generally include one or more display devices  535 , such as, but not limited to, a display screen, e.g., a cathode ray tube (CRT) or liquid crystal display (LCD), a printer, and one or more speakers, for providing information to a computing device user  180 . Embodiment computing device systems  500  also generally include one or more input devices  530 , such as, but not limited to, a keyboard, mouse, trackball, pen, voice input device(s), and touch input devices, which a user  180  can utilize to communicate information and command selections to the processor  510 . All of these devices are known in the art and need not be discussed at length here. 
         [0091]    The processor  510  executes one or more sequences of one or more programs, or applications, and/or software code instructions contained in the system memory  515 . These instructions may be read into the system memory  515  from another computing device-readable medium, including, but not limited to, the storage device  520 . In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions. Embodiment computing device system  500  environments are not limited to any specific combination of hardware circuitry and/or software. 
         [0092]    The term “computing device-readable medium” as used herein refers to any medium that can participate in providing program, or application, and/or software instructions to the processor  510  for execution. Such a medium may take many forms, including but not limited to, storage media and transmission media. Examples of storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory, solid state drive, CD-ROM, USB stick drives, digital versatile disks (DVD), magnetic cassettes, magnetic tape, magnetic disk storage, or any other magnetic medium, floppy disks, flexible disks, punch cards, paper tape, or any other physical medium with patterns of holes, memory chip, or cartridge. The system memory  515  and storage device  520  of embodiment computing device systems  500  are further examples of storage media. Examples of transmission media include, but are not limited to, wired media such as coaxial cable(s), copper wire and optical fiber, and wireless media such as optic signals, acoustic signals, RF signals and infrared signals. 
         [0093]    An embodiment computing device system  500  also includes one or more communication connections  550  coupled to the bus  505 . Embodiment communication connection(s)  550  provide a two-way data communication coupling from the computing device system  500  to other computing devices on a local area network (LAN)  565  and/or wide area network (WAN), including the world wide web, or internet,  570  and various other communication networks  575 , e.g., SMS-based networks, telephone system networks, etc. Examples of the communication connection(s)  550  include, but are not limited to, an integrated services digital network (ISDN) card, modem, LAN card, and any device capable of sending and receiving electrical, electromagnetic, optical, acoustic, RF or infrared signals. 
         [0094]    Communications received by an embodiment computing device system  500  can include program, or application, and/or software instructions and data. Instructions received by the embodiment computing device system  500  may be executed by the processor  510  as they are received, and/or stored in the storage device  520  or other non-volatile storage for later execution. 
       CONCLUSION 
       [0095]    While various embodiments are described herein, these embodiments have been presented by way of example only and are not intended to limit the scope of the claimed subject matter. Many variations are possible which remain within the scope of the following claims. Such variations are clear after inspection of the specification, drawings and claims herein. Accordingly, the breadth and scope of the claimed subject matter is not to be restricted except as defined with the following claims and their equivalents.