DistributedFileSystem? VersionedFileSystem? TransparentPersistence? Who knows. KillerFileSystem is the FileSystem for the KillerOperatingSystem. A current trend is eliminating the filesystem in favor of a database, as in ReiserFS, but this rapidly becomes an application issue.
Simply offer a different view of the database as if it was a file system, but when searching or having different glimpses of the file system available for users (virtual folders, type and find immediately) then make most use of the relational database. I.e. on a lower level, use the database.. but on a higher level, keep compatible with old file system treeview. Applications that make use of the new file system features should only be able to install on a system that has those new features avail.
See also
JustThreePersistencePatterns,
FileSystemAlternatives
ReiserFour?? ZeeFileSystem??
ZeeFileSystem? has some promising features, like the inherent versioning. However, it's still very far from the feature-set I'd really want in a FileSystem.
If I were to list those features that I know that I want in a KillerFileSystem, I'd be quick to note that many of them are difficult by themselves, and more of them are especially difficult when combined into one system (i.e. because feature A makes features B, C, D, and E non-trivial). However, here those features are:
- Efficient for both tiny and grand uses, to the point that the FileSystem could fulfill the role of all necessary mutable state.
- Atomic updates to files.
- Support for transactions over multiple files as an alternative to locks (which are especially heinous when failures occur).
- Automatic versioning for files updated by human labor, including who made which changes.
- Plus branching for files, so more than a single 'newest' version can be used where desired.
- Versioning with shared structure so the versions don't cost O(N) time to prepare and store.
- Convenient modal and capability-based access to historical files and certain branches of files, along with automatic branching. I.e. an admin could set a system up so it always 'boots' into the exact same condition it was in on DayXYZ for a new users (plus some limited knowledge of those 'new users'), but for older users will track the changes, while keeping the changes others make in their own private copy of the environment, well, private.
- Access to versioning and modal stuff for machine-updated files, too, though not necessarily on by default.
- Indexing:
- Not hierarchical in nature, though hierarchy may still be an option. Use a tag-based or feature-based system. Files might have unique names, but human names are just tags for humans. Things like types, users updating the file, times of updates, etc. should be among the features one can use, as are the contents of the files.
- Adaptive. If the current indexing doesn't support the searches requested by the users, it can offer to fulfill them by brute-force linear search or to create an index that will do the job. When it has multiple indexes that are not orthogonal in nature, or that are of very specific nature it should be able to unite them during some idle time to improve space and time efficiency.
- Must, of course, also support modal access as described above.
- 'Types' for files that are arbitrarily more complex than [Byte], and that are always fully and provably confirmed prior to saving the file. Values can include things like records, sequences, semantic tags, dates, numbers, strings, binary objects, and so on. The FileSystem (or at least the browser) itself is aware of some interpretations like audio, video, etc.
- Include access to and modification of structured parts of the file without loading or saving the whole file - i.e. equivalent of 'seek to byte' but for a more flexible set of structures. FileSystem must index into structure and be designed to achieve lower cost inserts and deletes from the 'middle' of a file.
- Partial files should be saveable, too, at least when human edited... but shouldn't overwrite the 'main' file and should be marked as incomplete (e.g. 'Draft'). This is mentioned here because the partial file might not be type safe.
- Representations for files separate from value and type (i.e. use codecs). A file typed as Text (or [Char]) may be stored in ASCII vs EBCDIC vs UCS-16 vs. Big5 without violating the overall type. A file typed as Audio might be stored as mp3, flac, etc. without violating its type as Audio. (I.e. keep representation separate from type.) With regards to integration to the ObjectBrowser and/or Applications, codecs themselves ought to be easily installed to the system so they are automatically usable.
- Presentation of files separate from value and type. While this is more part of an ObjectBrowser or Application environment, something like CSS ought to be available for files in general.
- TransparentPersistence -- the filesystem and its files can, when desired, be volatile or only memory resident.
- OrthogonalSecurity, Capability-based -- filesystem forbids access to files to which people lack rights, but agent A may grant agent B limited read/write rights to any arbitrary file.
- TransparentDistribution -- the filesystem can service multiple computers, and itself be distributed across multiple computers, with replication (mirroring, caching) as needed. The filesystem ought to be able to handle the difficulties with synchronization effectively.
- Subscription -- RSS-style feeds so one agent can know whenever another agent has modified a file within a timely manner.
- Subscription to 'features' other than filename would be useful, too. I.e. one could subscribe to all files that contain certain words.
- Subscription to attributes of a file or expressions over a file (rather than just 'whole-file' changes) would also be tremendously useful for efficient ReactiveProgramming.
- Open Source.
I am interested in knowing other features people believe are missing from that list, so feel free to add to it or comment on it. I'll refactor later.
Note FileSystemAlternatives (BeOS filesystem has been rather influential) and UniversalCatalog (a filesystem-like notion of RichardKulisz).
See: CrossToolTypeAndObjectSharing
CategoryFileSystem | NewOsFeatures
Killer File System