A file inconsistency is a state representing structural inconsistency within a certain group of a file.
File inconsistencies are exception conditions and are primarily caused by:
a nonplanned system shutdown. This could entail a system power-outage, a system crash, or when power to the system is inadvertently turned off (without first having been performed a shutdown necessary to guarantee synchronization of the virtual memory.) Normally, this only results in a problem if the hard disk was busy immediately prior to the outage and was not able to completely reflect some of the unwritten changes that existed in its memory to the physical disk.
indiscriminately clearing group locks that can open a failure window potentially causing a condition where two processes are simultaneously modifying the same internal structures, each unaware of the other.
overriding built-in file protections when using delete-file is problematic. Normally the system traps the condition of attempting to delete a file that is actively open by another process, but for compatibility with older releases you have the option of overriding this warning condition.
incorrect use of the System Debugger. The System Debugger gives the user total control of all the virtual file space and internal control tables used by the system. We recommend using caution when examining or changing spaces containing critical structures. See System Debugger in the System Administration Guide for a description of its commands as well as how to disable its use.
When a process encounters a file inconsistency, D3 invokes the File Inconsistency prompt displays to allow the process to attempt to resolve the condition before continuing. Each user can be configured as to whether or not the system should automatically correct the file inconsistency condition or stop and prompt the operator to choose the method for correction. This feature is controlled by the presence of m in the options attribute in the users file. The current system-wide default is to prompt the user for their intended action.
The D3 file system is comprised of items in files, with each file being divided into one or more groups in order to allow more efficient access to the items. Each group is consists of one or more linked frames of virtual space used to hold the items, or in some cases, pointers to the items. Each item stored in the group also has a small amount of additional information associated with it, called the item header. Determining which item goes into which group is based on a hashing algorithm that first calculates a checksum using the item’s ID and then performs a modulo function based on the number of groups that are in a file (called the file’s modulo.) More than one item can hash to the same group, in which case the group becomes a potentially endless chain of items and/or item pointers, with a well allocated file not exceeding one virtual frame per group. Memory used in D3 for both file storage and workspace is actually mapped into the physical disks in static units called frames. D3 frames are typically sized 4 KB.
Since the main computer does not work directly with this physical disk space, it is necessary for it to first be loaded into a temporary high-speed memory for accessing and performing any necessary changes to it before writing these changes back to the disk. The D3 Virtual Memory Manager is responsible for bringing these physical disk frames into real memory and then writing those that are modified back to disk. Additionally, ownership locks are asserted throughout the system on the items in files, on their groups, and so on to prevent another process from making changes to the above structures when someone else is viewing the same.
In summary, any problem where the system is unable to properly associate or perform any one of the above, can manifest itself as a file inconsistency.