Re: Implementing Meta File information in Linux (and a note at the

Vladimir Dergachev (vladimid@red.seas.upenn.edu)
Wed, 2 Sep 1998 16:56:04 -0400 (EDT)


> I don't know anything about RMS, but ORACLE uses raw disk for a reason..... To
> avoid letting layering give you the worst performance aspects of two storage models
> combined.
>

I think there is a good point here. My impression was that so far the
discussion focused on how are we going to implement "Meta stuff" instead
of what it is supposed to, what problem it solves.

My formulation is that with introduction of the GUI we _have_ to deal with
databases. In fact, /etc/passwd is nothing else but a database, though
one wasn't concerned very much with perfomance of it. GUI stuff is
different. There are multitude of settings which are kept in separate
files in different formats. In the process of using GUI (especially X)
the applications impose a severe load on the system. What is more nothing
is used effeciently - the time is spent doing stat calls, reading small
files randomlly of disk and parsing them.

This is not helped by (a reasonable) insistance of programmers on ASCII
configuration files.

Thus the solution to this problem should be a "database filesystem"
optimized for quick access to small parts of data and a lot of
crossreference between it.

This filesystem could be either contained in a separate partition or
looped back on a file.

A more exotic (and probably more efficient) way would be to put it in the
"end" of ext2 filesystem so that both could grow if needs be. This
integration could also have other benifits.

In other words there is a difference between a plain file (read continuous
chunk of infomation like binary,tex file or c code) and database file with
records in it. The latter should be treated specifically in order to
optimize perfomance.

One could also envision the file itself being associated with database
entries. In this context the copying of the file will copy the entries
as well. If one would attempt to copy the file outside of ext2 that should
produce those ".fork" database files.

Note that everything I mentioned here isn't new. We have gdbm and copying
can be very well patched to tag the db files around (change stuff in C
lib). The question is can we do it in such a way as to significantly
speedup the programs. I, for one, would really like my netscape to start
as soon as it loaded from disk and not several seconds later.

Vladimir Dergachev

> Hans
>
>
>
>
> -
> 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.altern.org/andrebalsa/doc/lkml-faq.html
>

-
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.altern.org/andrebalsa/doc/lkml-faq.html