Associated with the Mirus File System work items and issues.

MirFS (the Mirus Filesystem) is the filesystem used in Mirus. It is designed upon the following goals:
  • Provide a safe location for files to be stored
  • Provide facilities to recover lost files
  • Be self repairing
  • Be simple, but powerful
MirFS is meant to broach much of the issues surrounding Cosmos-based operating system filesystems - the lack of them. At the moment, only a few filesystems for Cosmos based systems exist. With MirFS, we aim to provide a standard of Gold Quality that other systems can look up to and design around.

The Mirus File System therefore has to be incredibly powerful and featureful. Whilst designing it, we wasted no expense providing advanced capabilities. For this to happen, it was required to research filesystems from various operating systems and see what seem to be lacking, and what seem to have what we need.

GruntyOS: Infinity
GruntyOS, a fellow C# operating system, has a filesystem called GLNFS, which stands for Grunty Linked Node File System. GLNFS bases around nodes and the linking thereof. Much of MirFS's code is inspired or based upon GLNFS code.

We also turned heads towards the ext2/3/4 file system. ext is a very complicated filesystem, but is very elegant. ext bases the file system off of filesystem blocks, block groups, and I-nodes. The filesystem loads a "superblock" (equivalent to a file allocation table), which contains information about the filesystem, as well as how the files are laid out.

One last concept that was heavily broached was the Fossil file system of Plan 9. Plan 9 is heavily networking based. Fossil is a further developed version of the original Unix filesystem. An interesting factor of the Fossil filesystem, as well as Plan 9 in general is the lack of utilities such as an FTP client or ssh client. The way Plan 9 operates is by linking these filesystems into the main filesystem, allowing traditional utilities such as "cd", "ls" or "cat" to operate on them as if they were local files.

Base Concepts
These things being considered, we can safely combine the best qualities of all into a list of concepts we want to be embraced by MirFS:
  • Everything is a file
  • All files can be operated upon by plain text utilities
  • Files can be grouped into directories
  • Directories can be grouped into other directories
  • All directories exist within the root directory
  • Drive letters and labels are irrelevant, and therefore not required
  • Local files and remote files are synonymous
Additional Concepts
  • All files and directories are file system objects, and can be equally represented
  • UNIX file permissions
  • Mirus user-based permissions in addition
  • No file extensions
  • All devices are read and written to via the filesystem
Taking in the concepts, a full feature list may be presented (no necessary order)
  • Symbolic and hard links
  • Journaling
  • Self-healing
  • Doesn't corrupt or fragment
  • Self-ordering
  • File deletion recovery
  • Extended file names
  • Extended attributes
  • Extensive permission system
  • UNIX-Like
  • POSIX compatible
Now, we'll look into the core components, concepts, and descriptions of the features and how they work.

Everything is a file
This is a core UNIX principle, and it should be embodied in Mirus. For example: all directories and files are files. All links and filesystem components are files.

Drive labels are irrelevant
Drive letters were created by Microsoft for FAT because of the invention of computers with multiple floppy drives, as well as hard drives, and have remained not only for backwards compatibility, but for sentiment. The very first advanced filesystem, the Unix filesystem, never intended for drive letters, and still does not to this day. Instead drives are mounted to a directory named (by tradition) either "/mnt" or "/dev", though it does depend on the developer on what they prefer.

Files, Directories, and FileSystemObjects
Taking the "everything is a file" principle a bit farther, Mirus makes all filesystem objects the same, as a "filesystem object". All directories, files, programs, binary files, etc., are all equal and considered filesystem objects, which can then be mapped into an abstract "file" or "directory".

Superblock/Master File Table
This feature is based on the ext file system. Instead of a "FAT", or file allocation table, the first bytes of the filesystem are taken up by a "superblock" or in Mirus' position, a "Master File Table".

The MFT describes the filesystem, as well as only the subdirectories of the root (where the MFT lives). Each directory (excluding the root directory), contains a "File Table" which describes the directory and its file system objects.

Last edited Oct 16, 2012 at 11:53 PM by joshbeitler, version 7


No comments yet.