elektra-semantics - Semantics of KDB
The use of arbitrary metadata has extensive effects in Elektra´s semantics. They become
simpler and more suited to carry key value pairs. The semantics now gives us independence
of the underlying file system. So none of the file system´s restrictions apply anymore. No
constraints on the length of a key name disturbs the user any more. Additionally, key
names can be arbitrarily deep nested. Depth is the number of unescaped / in the key name.
The directory concept is enforced by default. Keys can be created everywhere. Keys always
can have a value. The only constraint is that key names are unique and occur in one of the
namespaces elektra-namespaces.md. Every Key has an absolute name. There is no concept of
relative names in Elektra´s Keys except for meta keys belonging to a key. Every other Key
is independent of each other. We just do not care if there is another key below or above
the accessed one in the storage or not.
Some applications need specific structure in the keys. Plugins can introduce and enforce
relationships between keys. They can implement a type system, check if holes are present
and check the structure and interrelations. They may propagate the metadata and introduce
inheritance. We see that plugins are able to add more semantics to Elektra.
There are no symbolic links, hard links, device files or anything else different from key
value pairs. Again, most of these behaviours can be mimicked using metadata. Especially,
links are available using the metadata override and fallback.
Hidden keys are not useful for Elektra. Instead comments or other metadata contain infor‐
mation about keys that is not considered to belong to the configuration. If hidden keys
are desired, we can still write a plugin to filter specific keys out.
This section explains why using file system semantics for configuration is not a good
filesys was the first backend. It implemented the principle that every key is represented
by a single file. The key name was actually mapped to a file name and the value and the
comment was written to that file.
If the backend filesys was the ideal solution, Elektra´s API (application programming
interface) would be of limited use. E.g.cascading, type checking and optional cross-cut‐
ting features would be missing. The storage problem itself and the location of a key in a
key database would be solved. because well-established APIs for accessing files are avail‐
able in every applicable programming language.
Elektra 0.7 already supported more than one backend, but filesys was the only backend
implementing the full semantics.
Limitations of File Systems
Here we will discuss, why the file system´s semantics are not well suited for configura‐
tion at all.
One file per key turned out to be inefficient because of the file system´s practical limi‐
tations. In most file systems, a file needs about four kilobytes (Depends on the block
size, four kilobytes is a common value often used as default.) of space, no matter how
little content is in it. Thus the file system wastes 99.9% of the space if keys have a
payload of four bytes. Additionally, every file allocates a file node, which might be lim‐
ited, too. We can argue, however, that we can use a file system which does not have these
Many additional restrictions occur for portable access. The file name length in POSIX is
limited to fourteen characters. Additionally, issues with case sensitivity are likely. The
common denominator for all file systems is a surprisingly small one. If, for example, the
traditional FAT file system should be supported, file names are limited to eight charac‐
ters and case insensitivity.
On the one hand, there are many file system features that are not needed for configura‐
tion. File systems have a strict hierarchy. It is not possible to create a file in a
non-existing directory. We will refer to such a missing object as hole. File systems do
not support such holes.
A single root directory is not a useful concept for configuration. Instead, the system
configuration and each user configuration has its own root. These root keys themselves are
typically not needed.
There is additional metadata of files which is typically not needed for configuration:
atime, mtime, ctime, uid, gid and mode just to name a few. Additional file types, for
example, device files, links, fifos and sockets, are not needed either. Features like
sparse files are ridiculous for the small strings, that key values typically are.
On the other hand, there are many features missing in file systems that we need in a seri‐
ous key database. Creating a whole hierarchy of files at once atomically is not possible.
Ways to achieve this are currently academic and not portable. Directories cannot have any
content next to the files below. Swap semantics are missing: it is not possible to rename
a file without removing the target first.
To sum up, file systems are not suitable to hold configuration with one entry per file.
Instead, they are perfectly suitable to hold larger pieces of information like configura‐
July 2017 ELEKTRA-SEMANTICS(7)