LinFS/SQLFS project homepage

This page is devoted to my latest project, LinFS (and, simultaneously, SQLFS). Some words about this project:

  1. Idea:

    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...

  2. 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:

    1. UserFS

      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...

    2. CODA advanced distributed filesystem

      Not really an option for this task. Too complicated protocol, and mapping distributed FS to database neither obvious, nor easy.

    3. PODFUK

      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.

    4. HostFS, part of User-Mode Linux project.

      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.

    Well, after studying this options for some time, I saw that nothing of these is suited well enough for my project. So, I started to write my own implementation of LinFS. Oh, I haven't told you, what's the idea(s) exactly: Well, that's how I see it: you're doing
        mlinfs -u USERNAME -p PASSWORD -n DATABASE /mnt/db
        cd /mnt/db
    tables are directories,
        cd SOME_TABLE
    columns 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/sqlinput
        cat /mnt/db/sqloutput
    this 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 : Usually, database security rules and methods are more robust and feature-wise, than traditional UNIX mechanisms. So, using SQLFS as a storage place for, for example, users' home directories, would give administrator in a distributed environment ability to create, manage and fine-tune access to shared working areas, on a per-user basis. Also, SQLFS could be used for directories with hundreds of thousands of small files in one directory, f.e. sendmail's mqueue/ dir, or innd articles' spool, without significant drop of performance - indexed tables' search and retrieval of data is quite fast almost independantly of number of records. Probably, you've got an idea.

  3. History and status:

    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 :-)


Copyright (c) 2001 by Yarick. Created with Quanta+