A month later : a heads up on the project

My original blog concerning the projet was hosted on my personal webserver which had the good idea to went down when I'm 700 kilometers away. This blog is the alternative, at the cost of my previous entries.


The mid-term evaluation (July 15th) is now approaching. Even if I started the project with a big delay due to my studies it's now going well and I'm on schedule after a lot of work.

I spent the last few weeks digging into RTEMS CVS to see how file-systems are implemented, analyzing the ISO9660 standard (also known as ECMA-119), and finally starting the project.

ISO9660
My primary concerns was to understand the file-system structure and to be able to apply it to the RTEMS file-systems layer. It was not a big deal since I'm used to read standards about file structures.
Since ISO9660 is a pre-mastered file-system, it's very well organized : the directory tree is analyzed before creating the volume, which results in a clean and smooth structure, unlike read and write file-systems (EXT, NTFS, FAT32, ...) which have the bad trend to decay when inodes are added/removed.

ISO9660 volumes consists of a number of 2048 bytes wide sectors (in fact others sizes are allowed by the standard, but apparently rarely used). The first oddity of this file-system is that the first 16 sectors of the volume are unused, their content is unspecified by the standard and are considered to be filled with zero (although an application can use them as it want). It means that ISO volumes have a minimum length of 32 KiB.

Then first used sectors of the volume are dedicated to descriptors which ... describe various details of the disk. There is five different descriptors, each of them occupy exactly one sector :

• The boot record descriptor is almost unspecified and leave a big free space in the sector for bootable disk. Although it's not specified in the original standard, an other specification (ElTorito) describe how boootable volume should be organized.
• The primary volume descriptor contains various data about the whole volume, like his identifier, the creation date, path tables locations (see below), the root directory record (see below), the logical sector size, etc.
• The supplementary volume descriptor contains almost the same fields as the primary volume descriptor and could be used as backup.
• The partition descriptor can describe partitions across the volume, although it's not detailed in the standard
• The volume set terminator descriptor doesn't contain any useful data, his solely purpose is to indicate the end of the descriptors set.

The first task the file-system has to accomplish is to look into these descriptor and determine how it should handle the volume.