Phoenix File System

Although we plan to support many popular File Systems (FS's), including FAT, NTFS, HPFS, and others, we are also developing our own file system for Phoenix dubbed the Phoenix File System (PFS). PFS will use a node structure similar to the i-nodes found in most UNIX FS's. It also borrows ideas from other OS's. For example, the method used to keep track of free space versus used space as well as the idea of keeping directory information near the center of the disk is borrowed from HPFS.

As discussed in the documentation, PFS consists of several layers. At the bottom layer is the hardware device driver. The sole responsibility of the device driver is to read and write individual logical sectors, which includes translating logical sectors into physical locations on a storage device. The rest of the file system uses logical sector numbers to keep track of location. The next layer determines which logical sectors are used and which are free. The third layer groups data in data-chains, which are then grouped together to form data-trees. Each file node has three data-trees, one for the actual file data, one for Extended Attributes, and one for security information. These data-trees are controlled by the file nodes, which are very similar to i-nodes in UNIX. The file node is the file. It contains all the data about the file except for the name. The final layer is the directory structure, which contains the directory tree and filenames, with each filename having a link to a file node. Thus, files can be easily mirrored as two directory entries may link to the same file node.

To do:

• Discussion of DOS compatibility in regards to use of the extended partition type 05h
• Discussion of error recovery techniques
• Discussion of the entire Boot process
• Discussion of optimization techniques
  • Directory bands
  • Cylinder groups
• Discussion of format, partitioning, and volume creation processes
• Finalization of the SuperBlock format
• Misc. implementation guidelines for cross-platform support (such as standardized file locking semantics)
• Spell and grammar check documentation

Revision history of documentation:

Version 1.33a - 10/30/97

• Cleaned up some of the grammar/spelling/etc.
• Cleaned up the tables so that they all appear on one line (at least in 800x600)
• Removed references in tables to Sector Sizes of 256 bytes
• Added a rough, not-yet-final specification for the SuperBlock
• Added a few other links and other small stuff

Version 1.33 - 7/07/97

• Updated list of partition types
• Added brief description of PhoenixFS's use of and support of the DOS extended partition type 05h
• Added updated description of what information is provided by the NextSegment field in Segment Table Entries; NextSegment can select from up to 7 boot records (Master Boot Record plus up to 6 additional boot records located in Extended partitions (type 05h) nested arbitrarilly deep, up to 4 Partition Records per Boot Record, and up to 8 Segments per PhoenixFS partition (type B9h) for a maximum number of segments per physical drive of 224.

Version 1.32 - 6/28/97

• Described method of indicating that a Segment should be reserved for virtual memory.
• Reduced number of File Node flags bits used to indicate if file is compressed from 2 to 1. The idea being that PFS simply stores data compressed or not, encrypted or not. The file system itself doesn't need to know how the data is compressed or encrypted, and arguably doesn't even really need to know whether it is compressed or encrypted. The only reason flags exist at all is to allow a disk formatted with PFS to be transferred between systems, and even if the new system doesn't support compression or encryption it can still determine if the file is compressed and/or encrypted and perform error handling rather than give the user garbage.
• Changed format of symbolic links to allow references to network resources. Symbolic links can now include the method to retrieve the file as well as the location of the file. When the method to retrieve the file is given, the symbolic link uses URI format. If the symbolic link is not in URI format, the data is presumed to be on a local file system.

Version 1.31 - 6/22/97

• Revised ClusterSize field in Volume Descriptor down to 4 bits limiting the range for Volume Sector Sizes to a more reasonable 512-bytes at the low end and 16 Megabytes on the high end.
• Added Bad Sector List
• Added section for discussing how paths are formed titled "Directory Structure"; currently it is empty, but the hope is that eventually it will discuss how directories are organized in relation to volumes, how volumes are organized in relation to others, etc.
• Added idea of multiple directory bands to the SuperBlock. This is to account for the fact that a volume may span several physical disks and as such have multiple areas that offer prime locations for storing frequently accessed files such as directories.
• Removed Use int13h LBA Extensions flag from the Segment Descriptor Table since it interfered with cross-platform compatibility. Extra specifications added in the 1.30 revision to the Physical Layer eliminated the need for this kludge anyway.

Version 1.30 - 6/19/97

• Added directory format
• Updated Phoenix segment descriptor table to include drive serial number. The Volume Abstraction Layer uses device serial numbers to group multiple storage devices into a single logical volume. Originally it was assumed that the serial number would come from the hardware's serial number and special considerations would be made for devices without hardware serial numbers. Now, when the drive is formatted for use with PFS, it is assigned a serial number, derived from the hardware serial number, which is stored on the device. Many hardware serial numbers are only unique per manufacturer, so by creating a 20-byte (160 bit) binary serial number combining manufacturer, serial number, other device information, and random numbers we can be more certain to assign serial numbers that will almost never confict, even if a device is migrated between systems. This also removes much of the hardware dependence in the Volume Abstraction Layer.
• Fixed sector sizes in Volume information; since the Physical Layer requires sectors to be 512 bytes, and a Volume Sector is a grouping of such sectors, the minimum Volume Sector Size is 512 bytes (as opposed to the 256 listed in prior versions). This also extendes the boot code in the Volume Descriptor by 256 bytes.
• Changed Volume Descriptor field ("ClusterSize")indicating number of sectors per Volume Sector to 1 byte (rather than original word) and rather than being number of bytes per Volume Sector, the field now holds the log base 2 number of 512-byte segments per Volume Sector. This allows more sectors per Volume Sector, and reduces the size of the field, allowing for more room for other fields in the Volume Descriptor. Now, to determine the number of bytes per Volume Sector you raise 2 to the 8+ClusterSize power. For example, for 512-byte Volume Sectors, the ClusterSize would be 1; for 4096-byte Volume Sectors, the ClusterSize would be 3. Not that anyone will ever need a Volume Sector this large, but the maximum Volume Sector size becomes 2^263 or roughly 1.5e79 bytes.
• Added requirement to Physical Layer that Logical Sectors correlate to LBA sectors and/or Cylinder/Head/Sector so that the boot process can use Logical Sector numbers and relate them back to BIOS function calls.
• Removed SuperBlock Backup Table. Instead backup copies of the SuperBlock are stored immediately after every 16th Free Space Descriptor in the Volume. Free Space Descriptor locations are specified in the Free Space Descriptor Location Table.

Version 1.21 - 3/19/97

• Added Extended Rights format.
• Better described the boot process.
• Added SuperBlock Backup Table to record the locations of the backup copies of the SuperBlock.

Version 1.20a - 3/17/97

Version 1.20 - 1/25/97

Version 1.14 - 1/16/97

Version 1.13 - 1/11/97

Version 1.12 - 1/10/97

Version 1.11 - Obsolete

Version 1.10 - Obsolete

Version 1.01 - Obsolete

Version 1.00 - Obsolete