lkml.org 
[lkml]   [1999]   [Jun]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: File systems are semantically impoverished compared to database
Date
Theodore Y. Ts'o writes:
>> From: "Albert D. Cahalan" <acahalan@cs.uml.edu>

>> No, not like that at all. Structured storage adds an extra allocation
>> and namespace layer above the filesystem. This works in userspace,
>> but the performance is poor.

> I'm not convinced this has to be the case (that performance will be
> poor).

For now, every app with this problem has to implement something like
a growable (and hopefully shrinkable) filesystem within a file.
Apps can add a block mapping layer complete with triple-indirect
blocks, or they can copy around huge amounts of data and update
document references as needed.

>> You can get the performance today by using directories, but that
>> destroys usability. Documents need to appear as files to the user,
>> so they must appear as files to traditional POSIX software.
>> It isn't enough to patch a file manager. You'd have to bloat
>> everything in the whole system, perhaps losing the performance!
>
> That's why I suggested using a user-mode libc hack in cases where the

I greatly dislike playing with libc. There once was a libc that
would do compression, but it is dead now.

Static executables are a problem.

Every stat() call that acts on a directory must cause guessing,
perhaps by doing many more system calls inside the directory.
I doubt this would help with web benchmarks -- it will be disabled.

Without kernel support, the library would have to guess which directories
need special treatment. This is a bug unless you can explain how various
standards let directories suddenly and accidentally turn into files.
At the very least this is ugly behavior.

I hate to see libc full of heavy wrappers. Many filesystem functions
would have to do several additional system calls. Eew.

> should be just as performant as your NTFS "reparse point" approach ---
> with the added advantage that I don't have to implement "tar" in the
> kernel, which the "reparse point" approach requires. (OK, it's a
> loadable kernel module --- but it's still implementing "tar" in the

Note that we do have an NTFS driver. This driver is clearly missing
support for reparse points. Do you have a solution for that?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:52    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site