POrtable Dodgy Filesystems in Userland (hacK)

(alias podfuk)

What is it?

Podfuk wants to replace userfs. Reasons for podfuk are about the same as for userfs (filesystems in userland are easier to debug, and you can have completely new filesystems (tar) that would bloat kernel too much). Podfuk has few additional advantages over userfs: it does not require kernel patch, it is portable, it avoids C++, and if project crashes, we have at least nice new filesystems for midnight commander. It also has some disadvantages: we use NFS with all implications it has.

Why such name?

If your read uppercase letters in title, you'll get meaningful Czech word 'podfuk', which means something like 'fiddle'.

What is done?

Perhaps you'll like some demo?

pavel@Elf:/$ cd "/tmp/unarj241a.tar.gz#utar/unarj241a"/
pavel@Elf:/tmp/unarj241a.tar.gz#utar/unarj241a$ ls
Makefile       os2unarj.mak   tccunarj.mak   unarj.doc
Makefile.orig  patch241a      technote.doc   unarj.exe
decode.c       qclunarj.mak   unarj.c        unarj.h
environ.c      readme.doc     unarj.def      unarj.h.orig
pavel@Elf:/tmp/unarj241a.tar.gz#utar/unarj241a$ cd /tmp
pavel@Elf:/tmp$ head mc.diff.gz#ugz
--- /dev/null   Sun Jun  2 15:30:20 1996
+++ mmc/vfs/shared.c    Mon Mar 30 23:41:55 1998
@@ -0,0 +1,267 @@
+/*
...

It looks nice, doesn't it? OK, stay tuned, it is not as nice as it looks.

How it could be done?

OK, you want Linux to behave as above. What options do you have?

• Shared library hack - I tried to do this. It is hard to make it right since there's rather big interface between application&library. You have overhead at every open() and you have to patch things like exec(). Caching is hard to do as you have very limited possibilities to pass data around. Anyway, it looks like Miklos Szeredi actually did this one: his very interesting work, can be found at http://www.inf.bme.hu/~mszeredi/avfs.
• Kernel patch creating private protocol between kernel and user - this is what userfs does. I do not like it since it is not portable.
• Use some existing protocol - that's what is done in podfuk, and we are using NFS, because nothing other was suitable enough. NFS is both biggest advantage (it is portable) and biggest disadvantage (it is broken) of podfuk.
• Right thing - which would be create brand new, non-broken network file system, and build podfuk on it. Well, this is also hard to do, as designing good network file system is really non-trivial. Also, you would have to make every os understand your new network file system...

How is it done?

Midnight commander already had vfs layer. I have modified it quite a bit to make it much, much more Unix-like. I also turned mc's vfs layer into shared library so anyone can use it. Miguel already promised to roll my changes in in near future.

Then, I have modified rpc.nfsd to use this new shared library. So you can mount localhost:/ on /overlay and every time you want to access /path/virtualfile, you just use /overlay/path/virtualfile. It is not really user-friendly, but it is the best you can do if you want to keep it portable. (This has been tested on Linux only, so far. It should run without problems on anything close (FreeBSD). If you are successful, please report.)

This is usable, but not really convient to use: If you stay in /overlay all the time, it is slow (due to **** NFS); if you don't, you have to switch manually. To avoid this inconvience, hack to Linux 2.1.X kernel was created, which does necessary magic. [All accesses to non-existent file with '#' in name are redirected into /overlay file-system.]

Note that this hack is not required and if you are happy with manually-prepending /overlay every time you want to access virtual file, no kernel hack is required.

Version 0.1

Installing this is security hole. Which says it all. Midnight commander was not designed to be used by more than one user at a time, so all caches are shared etc. If you open private.tar file (600), anyone can see its contents, too.

No garbage collection is done. So your temp is likely to fill up. Soon.

This is not production quality. But it should work:

• Get mc-4.1.31.
• Apply mc.3.diff.
• Build mc. cd vfs; make libvfs.so. You should find libvfs.so in vfs/ directory.
• Get nfs-server-2.2beta29.
• Apply nfs.1.diff.
• Run ./BUILD script to configure it, then compile it.
• Install nfs and enjoy virtuality in /overlay.
• Check if it works.

If you are daring and want to try it with kernel hack, apply kernel.1.diff over 2.1.97 source tree.

Version 0.2-pre

Should garbage collect, should be OK from security point. Look into temp if temp files have right permissions with watchtmp, through.

Get this tgz, unpack it, run crazyinstall and follow its instructions.

Download 0.2

Good luck! You are going to need it.