• View
• Edit
• History
• Print

FileSystem

Author: Chani
Category: Core

(Telcontar notes: since this is in Plan, should it first cover the VFS daemon conceptually (as covered in VFSimplementation before covering the specific details of what the default file systems will offer?)

Cy/VOS is VFS based, so it can run arbitrary filesystems. In the future, however, Cy/VOS will make use of filesystem features not supported on conventional filesystems if those features are present. As such, a new design has to be considered.

Goals:

• Log-based filesystem.
  • Reliable, even more reliable than journalled filesystems.
  • Inherently self-defragmenting
  • Allows the use of transaction management. Rollback in a filesystem is a very promising feature.
• Multidimensional directories. Still a little fuzzy on how this will work, but it should allow files to present themselves in multiple filesystem views (semantic, organizational, related, project-grouped).
• Fully B-tree and B-fastarray-based.
  • Directories are stored as regular files, eliminating the overhead of storing them specially.
  • Files may be resized from any point. Data may be inserted into the middle of the file, or removed from the middle. Appending is only a special-case of this

Structured and managed storage

One of the great muses -- structured or unstructured storage? MS-DOS, Windows, UNIX and Linux all favour unstructured storage, but classic Mac OS and Symbian both favour structured storage: Mac OS has resource forks and Symbian OS has file stores.

One of the aims of structured storage is to all multiple programs to share a single file, such as to attach previews and icons, or to store various OLE objects inside a file as uniquely identifiable segments.

The general plan is for Cy/VOS to present structured file storage, using a system similar to Macintosh resource forks. There is also "managed" storage -- in this limited context I am referring to whether the application is allowed to see that the file is structured, or whether it can only gain access to it via an interface. By prohibiting each program easy access to the parts appended by other programs you can gain reliable isolation and allow for duplicate resources (type/ID). Generally the Mac relies on no two programs wanting to store the same resource type and ID within the same file, but Mac files only get one resource fork. Named forks would start providing some isolation.

Also: transparent conversion of the core data component to linear format for Net uploads or copying to foreign volumes where you want the remote side to read the data as if it came from a PC or *NIX box.