File system software???

[Scott Lystig Fritchie]

>>>>> "vs" == Vladimir Sekissov <svg@REDACTED> writes:

vs> Here are all links I have about the subject.
vs> User space libs:

I can add two cents, though I don't know if they're helpful.

Last year, before the USENIX Technical Conference in Boston, I worked
on a hack that would implement a "traditional", inode-based file
system inside of a Berkeley DB transaction environment.  I didn't have
an immediate need for it, but it seemed like a cool hack, because it
would allow you to do something like:

    BEGIN_TRANSACTION();
    fd = open(FILEA, O_WRONLY|O_CREAT);
    write(fd, buf, buflen);
    if (rename(FILEB, FILEC) < 0) {
        ABORT_TRANSACTION();    /* Naive error handling for example's sake */
    else
        COMMIT_TRANSACTION();

... which you just can't do with most file systems I'm aware of.

Someone from NetBSD, I can't recall who, asked me about the hack.
They were wondering about they might reduce the inode consumption of
the Ports Collection: it contains tens of thousands of mostly tiny
files in thousands of directories.  They decided to go another
direction, not that I blame them.  I haven't touched the code in a
year.

Combined with the library I'd helped write for the Sendmail BAMS
project, it could be a complete user-space file system and file I/O
drop-in solution: if the application doesn't use mmap(2), then you
probably don't need to modify any application code at all.  Once upon
a time, I'd compiled a shared library version and used the LD_PRELOAD
hack to get previously-compiled binaries to use it.  Worked pretty
well, although more apps than you might think use mmap() these days.

Trouble is, that integration work never got done.  :-)  If anyone is
interested, I can provide the code.  I'd slap a Berkeley-style license
on the DB file system code.  The BAMS I/O library has a sortof GPL'ish
kind of license, courtesy of Sendmail, Inc.

-Scott