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
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
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.
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
Log details of the file transations to databases, update web pages,
whatever. Its up to your imagination.
mv cannot be done across fs. Therefore, you must move data from the
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
|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
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.
KFS is available in 2 forms
For NetBSD 2.x KFS can be obtained
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
Firstly, apply the rename.patch
patch -p0 < rename.patch
Build the kernel. No need for special configs as the FS is loaded as an
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
Currently I am very busy working on the valgrind port to
, 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
Special thanks to der Mouse for letting me derive code from his
excellent pfs filesystem.
This project is hosted at: