lkml.org 
[lkml]   [1999]   [Jun]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: File systems are semantically impoverished compared to database

Lou Grinzo writes:

> namely the desired level of functionality. As I see it, there are
> two interesting levels of feature we're talking about:
>
> First, the ability to mash a bunch of file streams into a single
> disk file, ala MS's COM structured storage. This is clearly
> something that can be done wholly in user space, and would

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.

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!
The kernel can examine inodes and other structures directly,
so it can avoid much of the bloat.

> Second, the ability to assign semantics and characteristics
> to the albod itself and/or the files it contains. This is where
> things get really murky. In order to make albods work in this
> way, they need to be self-identifying, either through
> meta-data or via a signature. Meta-data has the problem of
> being easily lost, as others have mentioned, and signatures,

Huh? This isn't about tagging files with creator, MIME type,
author, copyright, etc. No, the document itself is multi-part.

> What level of functionality is truly desirable? My opinion is
> that just the first one, the standalone file mash, gets us 95%
> ofsirable utility (where utility is not identical to functionality),

Well, we already have that in userspace. Performance is not great.

> and in a very favorable form (no impact on the rest of the
> system, etc.). There could be changes made to some
> commands, to explicitly address the contents of a mash,
> but these could come later, and would be a separate effort.

There is no real need to let dumb commands access document
internals. It might be useful, but also cause trouble.


-
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    [W:0.098 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site