file system

The ability to mount filesystem's directory structure 'over the top of' existing mounted filesystems would allow for a number of simplifications for Haiku users' systems.

Details

Traditionally mounting a filesystem on a specific directory results in the new filesystem 'overriding' the specified directory, effectively hiding the original directory's contents. This restriction could however be lifted, allowing for layered, or union, mounting of systems.

When mounting filesystems the system will keep an ordered list of mount points. When file/directory/etc access occurs the system will traverse the mount list attempting to find a matching filesystem object in each in turn. The first match found is the one on which the system will act. Therefore, if there are two (or more) matches for a specific object the system first on the mount list will be used.

If the operation being attempted is that of file creation the system should create the file on the first read-write system found.

Usage

For Haiku users the system would keep a user specific set of directories with which it could overlay the system directories. Eg, A user may desire management of their own font directory. This directory could be mounted during login over the system font directory, thus removing the need for management of separate search paths.

The system would allow much freedom in areas traditionally protected due to permission constraints also. For example, installation of new software for a specific user is generally a difficult operation without resorting to increased privileges. However with layered file systems a user would have a (possibly blank) application directory mounted over the system application directory. Again doing away with multiple search paths and keeping the system much more cohesive.

Issues

• More specifics on handling of specific layers and filesystem operations?
• Does this system obfuscate the system internals where they are working adequately already?

Storing information about devices as attributes in the relevant areas of the devfs could allow much simpler (and more powerful) access to device specific data.

Details

There are many items of information regarding physical and virtual devices that require specialised APIs for querying. In order to implement this system an additional set of driver hooks could be added to retrieve the data. It has been suggested that using this method, driver complexity and extensibility (regarding PCI IDs) could be improved.

It would be possible, if the required functionality were in place and attributes present, to utilise a kernel enforced naming convention for devfs publication. Eg, "this is a IDE raw disk node, on the 1st bus master device" could be used to create a kernel defined devfs path.

Applications

Many applications exist such as,

• Video card frame buffer address
• Manufacturer ID and device string
• Ethernet MAC address

In addition to these examples the use of queries would provide an extremely powerful user interface to the hardware information.

Possible Candidates

• ZFS (very cool, snapshots, volume chaining (no more partition management...), interesting for query-only FS, compatible license)
• XFS (fast, proven, effective)
• roll our own (much work)

Extended File Type System

File types become more human-readable: Document, Image, Video, etc. In our local database we store the MIME translations for those types. Multiple-inheritance is supported, too (OGG would inherit from Audio and Video, for example). Instead of specifying attributes for each format individually (MP3 has its own attribute set) the attributes are inherited from the super type (Audio). Internally, the file types are stored as MIME. This allows for better OS-interoperability, backwards-compatibility, and more flexibility (we can change the inheritance structure of the whole type database and it will continue to work). But there is a problem with this model: global queries (Audio/*) would have to look for multiple MIME-types (application/ogg, audio/*, etc.). Nevertheless, it should be a step forward, usability-wise.

Hard-Link

The next file system should support hard-links and hard-link attributes for which you can choose the desired file type of the target in the attribute's specification.

Extended-Link and File IDs

Every file gets a unique ID that does not change when it is moved (unlike the inode). An extended link consists of a volume ID and such a file ID. It is similar to a hard-link, but without increasing the target's reference count. Extended-link attributes can have a desired target file type in the attribute's specification.

Multi-Value Attributes

Attributes are allowed to have more than just one value. For instance, a contact may have multiple email addresses.

Ranges

Sometimes one might want to define a range of possible values for a value (most appropriately an integer or other numeric type). For example:

• percentage (task accomplished)
• rating (music)

Enumerators

Enumerators are 64-bits values which represent one of a defined set of string values. The 64bit value should where possible be the UTF-8 representation of the value, or as close as possible for interest of human readability. Users should be allowed to add their own values to an enumerator.

Extensions

An extension allows for adding a collection of additional attributes to a file or folder (as if it had inherited the attributes of multiple file types). You can add any number of extensions independent of the file's type. Internally, a multi-value attribute stores which extensions are used by a file.

Virtual Attribute Groupers

Sometimes you want to have the values of multiple attributes collected into one attribute. Take email recipients as an example. Instead of accessing "To", "Cc", and "Bcc" individually, when creating a query or when categorizing files, you use "Recipients". This attribute does not really exist on the volume, but is generated to simplify attribute handling.

Actions

Each application says which actions it can perform on a given file type. BeMail would say that it can do the following (optional arguments are in brackets):

• "Reply to" "Email"
• "Write Email" (to "Person")
• "Forward" "Email" (to "Person")
• "Send as Attachment" any type (to "Person")
• default: "Read" "Email"

These actions can be executed from within Tracker and supporting applications.

Categorization

The contents of folders and files can be categorized and subcategorized by attributes. This facilitates categorizing a query for "Audio" files by "Genre" and one level deeper by "Artist", for example. The root category "All" should still be shown in case the user wants to work with all matching files.