A overlay filesystem for whofig

In order to bring about an easier migration to the whofig system, which organizes an operating system's files based on who is responsible for them in addition to what they are about, it might make sense to build a special filesystem tool.

They key would be to implement an "overlay" filesystem, something not commonly used in unix/linux, though found by default in some other operating systems. There have been such projects for linux, and indeed most live CD and rescue disk systems work by using a writable ram-based overlay filesystem on top of the read-only CD filesystem.

An overlay filesystem lets you mount one filesystem on top of another, so that directories with the same name become a combination of the directories from the two (or more) filesystems. Files of the same name generally cause the return of a file from the "superior" filesystem.

For example, today if you mount a filesystem on "/usr" it replaces all directories in the base filesystem that might have been under /usr. In an overlay filesystems, the files of both systems remain available. It requires some cacheing of the directory tree of each system to remain efficient.

For whofig, a special overlay filesystem could be built, and legacy packages that don't understand whofig would have some or all of their files placed in the base filesystem.

For example, many tools have a configuration file in /etc. A simple example would be /etc/samba/smb.conf, the control of the Samba (Windows) network filesystem daemon. Samba, when installed, would of course create this file with all of its standard defaults.

A second filesystem would be overlayed. When, as sysadmin, you wished to change the configuration of samba -- as you always do because you need to add the filesystems you plan to export -- you would use special tools which encapsulated your changes as a "patch" to the default file. The resulting file, the way you like it, would be put into an overlay on top of /etc/samba/smb.conf, so that Samba and most other tools would read the modified file.

Attempts to write to the overlayed file, even by root, would actually result in the creation of a patch showing the differences between the base file and the new version, and that patch would be stored in a file tree belonging to the party doing the changing, joined with other patches done by the same party.

If there are multiple changing parties, all the various patches must be considered. It's always possible to generate a patch -- in the worst case you can just completely replace a file -- but ideally you want it to be clean.

This can get messy, so of course it will be encouraged to use special tools which make this process a bit more explicit. Something quite similar to the way we handle version control systems like CVS. Incompatible changes by different parties should be displayed so a human can resolve them.

For binary files -- and alas we will want to know the difference -- generally a new binary file will just overlay the old one completely. Fortunately in most cases, tools typically just add binary files (such as plugins and modules) though sometimes they use binary databases.

Of course, the goal is for the packages to become more and more whofig friendly, even if they still use the overlay filesystem. The more they isolate local changes, even within their own sets of files, the easier it is for an overlay filesystem to partition them fully. The long term goal would be to actually move away from the overlay filesystem to more explicit tools.