This page is devoted to my latest project, LinFS (and, simultaneously, SQLFS). Some words about this project:
Idea of LinFS came to me, when I was struggling with command-line driven tool (INL) for Linter RDBMS, trying to do some simple tasks. Linter has some decent management tools, available, unfortunately, only for Win32 platform (Unix/Linux tools are just being ported now), so effective database management was mostly a dream under my favourite platform (Linux). I had some previous attempts to ease task of using Linter's capabilities before (look into My Projects page, if you're curious), but I needed an ultimate :-) solution, And idea of viewing and manipulating database objects quite like ordinary filesystem objects was the best I could imagine, althouh a bit weird at first. I tried to imagine, how it could look, and what is needed to implement such a thing...
Implementation principles: It was obvious - I need to write a filesystem. Moreover, this FS must be based mostly on user-space libraries (inserting Linter database access library into kernel isn't possible for many reasons). So, I started searching filesystems capable of retrieving FS objects' data from userspace programs. There are quite a few of them:
Unfortunately, userfs development stopped some time ago, and it don't compiles under 2.4 series kernels. Probably , fixing userfs to work with recent kernels was better idea, than reiplementing this wheel from scratch, but , you know, learning how to write filesystems, along with learning linux kernel internals is a lot of fun...
Not really an option for this task. Too complicated protocol, and mapping distributed FS to database neither obvious, nor easy.
POrtable Dodgy Filesystems in Userland (hacK). Tries to wrap CODA using Midnight Commander's VFS library. Nice and funny hack. However, after briefly skimming through code, I'm feeling this isn't an appropriate direction either - limitations are obvious, although not deadly.
Not really a solution, 'cause hostfs needs to be ripped off from this project, but I surprisingly have found the same idea inside mentioned page, which came to me earlier (mounting database into directory). Maybe, one time hostfs will evolve into separate project.
mlinfs -u USERNAME -p PASSWORD -n DATABASE /mnt/db cd /mnt/db lstables are directories,
cd SOME_TABLE lscolumns are files (or directories,too, each approach have its advantages and disadvantages)
less COLUMN egrep "Pattern" COLUMN wc -l COLUMN cp COLUMN /DbBackup/SOME_TABLE/and so on. This thought enlightened me for a second - spending time to write database management tool is a waste of this time, when you could manage databases from your favourite file manager or shell, be it bash, mc, konqueror or something other. Using SQL could be as simple as
echo "SELECT COLUMN FROM TABLE WHERE COLUMN2=SOMEVALUE;" > /mnt/db/sqlinputand
cat /mnt/db/sqloutputthis was the main idea of LinFS. Another one cames to me at a regular basis :-) - using SQL database as a remote secure storage, with database-implemented security mechanisms. Of course, such FS will not be the fastest available, but it could be :
When I started working on LinFS, I have zero knowledge of how to write filesystems (source shows it clearly :-). Current status of code is "proof of concept". I.e: it IS buggy, it CAN and, probably, WILL HANG your machine or give you good solid kernel panic. I'm leaving current LinFS sourcetree as-is and starting from scratch. If you want to help in development of LinFS/SQLFS , you help will be GREATLY appreciated - I don'l like coding alone (this is the main reason of my projects being unfinished). So, if you want to participate in this project(s), contact me. Coding is fun, this project goes to be some special kind of fun, either :-)