IFS allows merging several file systems in a stack-like way, such that files from lower layers become visible only if there are no files with the same path in an upper layer. Furthermore, all file creations and write accesses go to the top layer, which can be used to create the effect of having writable read-only media (e.g. CD-ROMs). See the README file for more details.
IFS was heavily inspired by Sun's Translucent File Service (TFS) but extended it to allow virtually any number of overlaid file systems, where TFS only allowed two. I started IFS in spring '93 and released the latest version for 0.99pl11/0.99pl12alpha kernels in summer '93. There's been an update for 0.99pl14 kernels in spring '94. (Don't know who did it - that person unfortunately didn't leave his or her name in any of the files.)
There has been no further development and the interfaces IFS uses in the Linux kernel have undergone thorough changes and bear very little resemblance to what I used back then, so updating IFS would probably be much harder than to start over from scratch. Here's what I wrote to the linux-kernel mailing list a few years ago on the issue of IFS:
Well, I completed it to the point where it was a nice proof of concept, but still with problems (leaks inodes, probably has a few races left, was also a bit too liberal with locking, etc.).
Then I looked back at what I did and was disgusted by its complexity. So I decided that, before I might even consider proposing inclusion into the mainstream kernel, I'd have to see how much poorer (performance-wise) a user-space implementation would be. I did some initial hacking on NFS until I convinced myself that userfs might be the better approach. Unfortunately, I never found the time to work on that.
I also noticed that amd should have some functionality that provides at least a subset of what IFS could do (you can quite easily apply the concept of IFS to caching, CD-ROM "writing", storage management, etc.), although I never actually tried that part.
If I had time to work on it today, I'd probably go for a mixed kernel/user space approach: do all the bookkeeping and special cases (device files, named pipes, etc.) in user space, but keep data transfers in the kernel. I'd also investigate into the direction of COW semantics for disk blocks in order to reduce the cost of changing a few bytes of or appending to a "read-only" file.
Sounds like a very nice master's thesis topic for some good Linux hacker ;-)
Update: In 1998, this page ended with So far nobody has taken the challenge. Fortunately, some people have by now. An overview of similar projects can be found here.
- Werner
Werner Almesberger, 19-APR-2004