When a VFS operation is not managed by KFS, it is relayed downward to the underlying filesystem such as FFS and is handled accordingly.

How are VFS calls intercepted?

Kfs is a layered filesystem that receives VFS operations from userspace, intercepts it and sends it back to the userspace. In the userspace, the daemon listens for request, and handles it appropriately. There are two levels of abstraction for most VOP_* that are intercepted. The first level is at the VOP_*. The user can write simple C code to customise the action. The second level is by mime-type. Using libmagic, the mimetype of the file on which the VOP_* operation is performed is determined. According to that, a  plugin can be loaded to perform custom action.

So what can it do for me?

Currently, Kfs is in early stages of development, hence the code just intercepts one VFS operation, the rename system call. This itself is sufficient to implement  a fully auto sorting filesystem for netbsd.
An overview of how this is done is shown:

Yes, all this is a little time consuming, but the fs is mainly intended to enhance user experience.

MimeType specific plugins

These plugins can be written in simple C, a skeleton plugin is provided in the source to guide you along.
A script handler is also provided, this handler is to allow arbitrary scripts to be executed  on mimetypes with Kfs, again, documentation and an example script that can be run on mp3's is provided.
The configuration file currently also supports the default action of mapping filetypes to directories. For example, pdfs can be directly thrown into a directory called PDF\ Files/ or such.
Another plugin to interface with the rainbow program, is provided. I am aware that it does not compile cleanly under netbsd, I shall package this soon.

Playing with KFS

Once the fs is mounted, the directory becomes "smart" One can immediately start using it through a file manager or the shell. Warning: There is a lot of debugging output that the kernel spews, this will only go away once KFS is close to release, it does not lead to kernel panics or anything but its just incomplete as of now.
Example:

modload knowfs.o  #loads the lkm mount_know -f config /home/someone/smart /home/someone/stage # smart is the directory thats intelligent. stage is the backing store

Now, all VOP_RENAMEs to the smart folder will be intercepted by KFS. The use of the mv program to drop files into the smart folder will result in the data getting sorted automatically. 
For example one can just state that all pdfs go into a pdf/ folder, and all mp3s are to be  parsed by a mp3.s script. A drag and drop into this folder, will cause the action to be taken on the file.

Sorting is not the only thing you can do with the current incarnation of KFS. You can write scripts to normalise mp3s, fix their id3 tags and so on.
Log details of the file transations to databases, update web pages, whatever. Its up to your imagination.

Limitations

mv cannot be done across fs. Therefore, you must move data from the same partition as the one in which directory that is the backing store is under. For example, if
/home/stage is the backing store, and /home is a seperate partition. Then only  data from /home can be sorted.
Once more VOP_* can be intercepted, the features of the FS will become richer.

Doing

mv /home/smart/something/somefile ..

will result in the file disappearing. This is because the rename op works as a link followed by an unlink of the original file. something/somefile is where the somefile will come back to, given the config. Therefore once somefile is linked, it is unlinked again. Thus doing

mv /home/smart/something/somefile ..

will cause somefile to come back to /home/smart/something
followed by it being unlinked.

The kernel patch included with the distribution needs to be applied. VOP_RENAME  must be taught to propagate rename calls to the fs to the destination target, and not the source target. This does not break existing  filesystems in anyway. It allows layered filesystem to deterimine if the FS below it is the same as the FS from which the file is coming from.
When linking works across layered filesystems, why not rename?
Perhaps this patch will be integrated into the NetBSD kernel soon.

The filesystem can lead to problems, its incomplete, please do not put sensitive or important data in it unless you know what you are doing.

Getting it

KFS is available in 2 forms

For NetBSD 2.x  KFS can be obtained here.

For NetBSD 3.x KFS can be obtained here. ( this may work for -current too, unverified)


VFS changes between the NetBSD 2.x and 3.x warrant different distributions for the LKM.

The full project report on KFS is available here.

Installing it

Firstly, apply the rename.patch

cd /usr/src patch -p0 < rename.patch

Build the kernel. No need for special configs as the FS is loaded as an lkm.

Running make on the toplevel should build all necessary files.
Running make install should put the required data into /usr/local.
The mount_knowfs in bin/
Plugins in lib/knowfs/
Scripts for the script plugin in lib/knowfs/scripts
The lkm goes to /usr/lkm/ where all lkms are put.

Snoop around read the source and enjoy

Status

Currently I am very busy working on the valgrind port to netbsd, so I have not planned any new releases soon. The FS will definitely not stagnant, as I have many ideas for it in the TODO list. If you are interested to work on it or have ideas or feedback , please mail me at

hsaliak at gmail dot com

Acknowledgements

Special thanks to der Mouse for letting me derive code from his excellent  pfs filesystem.

This project is hosted at: