Re: Hurd features (continued)

[olafBuddenhagen]

Hi,

On Mon, Feb 12, 2007 at 08:23:57PM +0200, Constantine Kousoulos wrote:

> Out of curiosity, can you please mention what are the main hurdish
> features that a native filesystem would put to use? Couldn't those
> features be incorporated into one of the existing filesystem
> translators?

This is one of the (many) topics I want to write up something on, but so
far haven't managed...

In short, the idea is that Hurd translators allow viewing structured
data as a directory tree, which is a very powerful concept IMHO. The
problem arises, if such trees are backed by actual disk files. Storing a
complex structure as individual files and directories is extremely
inefficient in a traditional filesystem, regarding both storage space
and processing time.

Alternatively, one could store the actual data in some serialized form,
like XML files. (Or s-exps or whatever.) However, this is also extremely
inefficient and even fragile: If you change something in the tree
representation, e.g. replace a single entry by a larger one, the backing
text file will have to be rewritten completely starting with the
position at which the change happened.

Of course, with some special DB-like storage format, it's possible to
create more or less efficient data structures on top of normal files;
but this is rather complicated, fragile, and intransparent, and the
resulting structures can be processed only by using the DB translator --
unlike traditional directory structures or XML files, which can be
processed with standard tools. (Which is a problem especially when you
want to access the partition from another OS, but limits flexibility in
the Hurd itself as well...) Also, you get a disruption between the
normal directory structure, and the internal structure of the DB files
stored in it -- in some applications, it's rather arbitrary where to put
the division.

Ideally, there should be no division at all -- the FS should handle this
transparently, so complex data structures can be efficiently stored
"natively", and presented in either the expanded or the serialized form
as needed.

I don't think traditional disk filesystems can be used for that. It
requires a very different on-disk data layout.

-antrik-