[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Hurd features (continued)
From: |
olafBuddenhagen |
Subject: |
Re: Hurd features (continued) |
Date: |
Thu, 15 Feb 2007 00:02:56 +0100 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
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-
- Hurd features (continued), Shams, 2007/02/04
- Re: Hurd features (continued), olafBuddenhagen, 2007/02/05
- Re: Hurd features (continued), Shams, 2007/02/10
- Re: Hurd features (continued), Shams, 2007/02/16
- Re: Hurd features (continued), olafBuddenhagen, 2007/02/17
- Re: Hurd features (continued), Shams, 2007/02/18
- Re: Hurd features (continued), olafBuddenhagen, 2007/02/20
- Re: Hurd features (continued), Shams, 2007/02/21