Frankenstein's File System – A Simple Indexing File System

This document is still work-in-progress, it will be cleaned up and re-orgranised as progress is made and ideas are refined.

The idea is to design a simple indexing filesystem. The 'point' being merely for amusement, though if it does result in a usable/useful design, that wouldn't be such a terrible thing.
Unofficially titled Frankstein's File System or FFS (For F***'s Sake?) for short. Though people might want to settle on the more conservative Simple Indexing FileSystem (SIFS). Any other ideas are welcome.
All ideas/objections/insults are welcome. The only restrictions are that it should be simple (straightforward and easy to implement) and indexing (surprisingly? This really just feeds off the simplicity aspect.)

Features:

Exactly what, how, and how many of these should be included is up for debate, just as long as we don't over-complicate the design.

Bootsector
The Index!! -- not really part of the 'interface' but obviously a necessary part of the design. Will basically map the files onto the disk (in some way.)
Files
Directories/Folders - maybe not entirely essential, but definitely useful.
Time/Date stamp - again, useful.
Attributes - somewhat useful? Exact attributes to be decided.
Permissions/Ownership - security. Requirement depends on use, but it's a desirable feature.
Journalling? - Probably a little too much overhead/complication, but error recovery/robustness aren't bad things.

Basic Structure:

The top-level structure of the filesystem consists of a collection of sections, layed-out sequentially on the disk. Each section will be of a pre-defined class to identify its contents; sections may appear in any order on the disk, and sections of the same class could appear more than once for different data, unless otherwise noted.

To be compatible with the bootstrap mechanism of current PCs, the first sector should be reserved for a bootstrap program, with execution beginning at offset zero of this sector. The purpose of this program is to load a file (or files) from the disk in order to start the Operating System, however, only this first sector is initially loaded and the program itself is responsible for loading any other necessary sectors and/or files. With only limited space (one sector; generally 512 bytes) in which to do this, the program would struggle to load files from the disk without extra information to aid it.
For this reason, we reserve a small number of bytes at the end of the boot-sector in which to store the minimal necessary parameters required to load a file from the filesystem; leaving the rest of the bytes preceeding this for the boot program itself.
Bytes 510 and 511 (the 'last two' of a 512 byte sector, but sectors may actually be larger) of a bootsector are convetionally reserved for a boot-sector signature of "55 AA" (hex) to indicate the sector does indeed contain a valid boot program. Is this technically needed? It's required for the MBR, but when the MBR progam loads the bootsector from a partition does it actually check? Need to look at grub/lilo/etc.

This gives the following layout for the boot sector:

    +-----------------------------------------------------------+
    |                                                           |
    |                                                           |
    |                                                           |
    |                                                           |
    |                                                           |
    |                       Boot Program                        |
    |                                                           |
    |                                                           |
    |                                                           |
    |                                                           |
    |                                                           |
    |                                                           |
    +-----------------------------------------------------------+
    |                                                           |
    |                        Parameters                    _____|
    |                                                     |55 AA|
    +-----------------------------------------------------------+

And a general overview of the entire filesystem:

    +-----------------------------------------------------------+
    |                        Boot Sector                        |
    +-----------------------------------------------------------+
    |                                                           |
    |                                                           |
    |                          Section                          |
    |                                                           |
    |                                                           |
    +-----------------------------------------------------------+
    |                                                           |
    |                                                           |
    |                          Section                          |
    |                                                           |
    |                                                           |
    +-----------------------------------------------------------+
    |                            ...                            |
    +-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --+

Sections:

Each section consists of a header, followed by its content data. The header contains basic information that is common to all sections, such as the class, length, ...
This format allows a basic implementation to parse the structure of the filesystem, even if it contains sections of classes it does not support. For this reason, implementations should ignore any sections of classes they do not understand; this does mean that any defined extensions should not break a basic implementation by including essential information in a non-standard section, as this could cause the basic implementation to corrupt the filesystem. All standard sections are those essential to basic use of the filesystem, i.e. traversing directories and reading/writing files.
Such flexibility also allows easy error recovery; a disk repair tool could traverse/search the sections independently of on-disk data, thus allowing it to recover lost files even when the data required for normal filesystem access to them is lost.

Section Header:

Class — four character ascii string
Length — unsigned 32-bit length; congruent to 512
..?

Section Classes:

The class of a section is specified by a four character ASCII string, giving the name of the section. Names consist of a limited alphabet of alpha-numeric characters, plus underscore, all other characters/symbols/whitespace should be avoided. All names beginning with an uppercase alphabet character (A–Z) are reserved for the standard and its future extensions, leaving all other names free for personal use and OS dependent features (since implementations will ignore unrecognised sections, this should not cause any problems.) Names are, therefore, necessarily case-sensitive.

"FILE" — file - files exist only in directory entries?
"DIR_" — directory - contains records for the files it contains
"INDX" — index - map of sector allocations
"DATA" — start of file data?
"INFO" — extra information - like what?
"JRNL" — journal
"END_" — current end of sections (i.e. no more sections follow this one)

File Record:

Name - 64 chars with option to be exetended, or 255? (ascii? uincode? utf8?); zero-terminated or length prefix?
Size - 32 or 64 bits? (32 = max 4GB, 64 = max 16 million TB)
Created/Modified/Accessed date-time -- elements (bits allocated for year, month, day, etc) or counter (seconds: 32-bit = 136 years, 40-bit = 34841 years, 64-bit = 584 billion years; milliseconds: 48-bit = 8919 years, 64-bit = 584 million years)? reference point (1900, 1970, 2000)??
attributes?
owner?
access rights/permissions?

Index:

hmmm...

Appendix A – A standard FFS bootstrap program

include here the code for a simple (x86) bootstrapper that loads a file by name from the filesystem, and transfers execution to it.