The High Performance File System (HPFS) was introduced with OS/2 version 1.2. It was designed by Gordon Letwin, the chief architect of the OS/2 1.x operating systems. HPFS uses different structures, caching and allocation techniques to achieve superior performance over the File Allocation Table (FAT) file system.
What follows is a highly technical discussion of the internals of the HPFS disk structures and organisation.
The HPFS has only three items which have a fixed location. The first is the volume boot sector which starts at logical sector 0. Sectors 0 to 15 are reserved for the boot sector and up to 8K of disk bootstrap code. The boot code can access HPFS in a restricted mode; enough to ensure the system is booted and running to the point of being able to load HPFS.IFS - which is the real HPFS driver.
Located at logical sector 16 is the Super Block. The Super Block contains the following information:
The Super Block is only modified by disk maintenance utilities such as CHKDSK HPFS-Bad, HPFSDfrg and HPFSView.
A complete description of all fields in the Super Block is contained in Appendix I - DiskEdit Modules.
The Spare Block is at logical sector 17. It contains the following information:
The Spare Block is modified, (although infrequently), as the system operates.
A complete description of all fields in the Spare Block is contained in Appendix I - DiskEdit Modules.
As can be inferred from the above information, the layout of the HPFS volume looks similar to the diagram below:
The fundamental file system object on an HPFS volume is an FNode (pronounced "eff node"). The FNode contains the true length of the file name, the first fifteen characters of the file name (so that disk recovery utilities such as HPFS-UD can recover deleted files or files from damaged volumes), a pointer to the FNode's parent directory (to enable you to build up path information), extended attribute information and information regarding the position of the data sectors for the file itself. If the file is in eight or less extents, the FNode has room to contain the starting sector and the number of sectors for each sector run.
If the file is in greater than 8 extents, an extra allocation node (or ANode), must be created. There is room for 12 ANodes in the FNode. In this case, the structure of the FNode changes to resemble this:
In this example the ANode contains direct sector runs, not further ANodes.
ALSECs Each ALSEC has room for 40 direct sector runs or 60 pointers to further ALSECs. There is no limit to the number of ALSECs which can be allocated. They will continue to be allocated until they can contain all of the sector runs for the file. Each ALSEC is one sector long.
Similar to files, directories are anchored on FNodes. A pointer to the root directory FNode is located in the Super Block. Directories are built up of DIRBLKs. Each DIRBLK is four sectors long They are allocated as four contiguous sectors. Once the directory band is full, they are allocated where ever there is space. The directory band is located near the seek centre of the disk for performance reasons (less head movement). The DIRBLKs are composed of variable length records which represent each directory entry. They are called DIRENTs. Each directory entry contains the following information:
When a file is deleted the complete directory entry is overwritten. Thus, information such as the complete filename and other attributes is lost. The undelete process can only process information found in deleted FNodes; which is why only a limited amount of information about files can be recovered from HPFS volumes.
There is room for 316 bytes of extended attribute data, or ACL information in the file's FNode. If the amount of extended attribute data exceeds this it can be moved to external sector runs which contain the data; or even an ALSEC to describe heavily fragmented extended attribute data.
There is a bug in the current implementations (both HPFS and HPFS386) of the HPFS.IFS driver. A file's EA's will be lost when the number of extents needed to store the EA exceeds 40.
This is scheduled to be fixed in a future release.