Re: reiser4 plugins

Daniel Arnold
2005-06-24T23:43:58Z

Hello,

I looked at the whole thread regarding "reiser4 plugins" via Kerneltrap and
felt myself committed to say thank you to those people like Hans that have a
vision and are working hard to let it come true (and not only talk about what
might could be done ;-) ).

See the following comments as a pure outsiders user perspective view (Note: I
have virtually no knowledge of the technical kernel internals) of the
possibilities that Reiser4 and related technologies provide for our beloved
Linux operating system as I fear that you missed this view somehow in your
heated debate:

Although I'm currently using ReiserFS v3 at my (Suse) Linux box (and am happy
that it uses my small hard disk space better than other file systems and that
I could always repair the data on the file system in some minutes at least in
large parts in case my _hardware_ caused a system crash; I had a evil
graphics card...), I'm very excited of the possibilities v4 provides and
wonder why there are people at LKML that don't see those possibilities
although they have a lot of more knowledge than I have on files system issues
(as I'm mainly a user). Perhapes some are beside technical concerns trapped
into to a "traditional Unix religion" (for me this is the real reason why
e.g. the free BSD's are constantly forked, as everyone thinks he has found
the only true way in the "Unix religion").

Here are only some possibilities that come into my mind regarding Reiser4:

One big thing are all the nice applications that want databases like MySQL. As
they need that extra database software with its own tools and structures they
are often too complicated for a normal end user. Having the same software
using an intelligent file system without need for a special database would be
a big step in end user usability especially but not only at the desktop. And
of course you can easily manipulate your database with easy standard tools
like a file manager or from command line like cp, mv, rm which would be again
a big step back to simplicity.

Another idea is a CVS-like revision file system. Especially in /etc/ this
would help a lot... Imagine a revision-plugin for Reiser4: This system would
be self documenting as you don't need to keep in mind where, when, what you
changed (and for system scripts it would be easier to track the manual
manipulations; especially a problem at system upgrades). You could easily
make a diff of two revisions of a file e.g. for /etc/squid/squid.conf (a huge
single config file) with standard command line tools like diff (like
"diff /etc/squid/squid.conf/rev-0 /etc/squid/squid.conf/rev-current").

Another possibility would be e.g. replacing the RPM-database by a structure in
the Reiser4 file system. Imagine the structure of the rpm database which
software is installed sitting below /etc/packages/, e.g.
in /etc/packages/apache/. With removing the /etc/packages/apache/ directory a
clever Reiser4-plugin would instantly remove the whole package (don't know
how to handle the problem of executing necessary system scripts during that
procedure though). That this idea is highly demanded can be seen on Apple
computers and on a wired approach at a new FreeBSD distribution called
PC-BSD, where everything of a application is installed in a own separate
directory as on Windows...

Of course there are competiting approaches to this problem via hiding the
database structure to the user and reinventing again the file system level as
e.g. FUSE (which is/was also controversial at LKML but also highly demanded by
end users). You could also mount a rpm database with a proper FUSE-plugin and
let it look like a file system but this approach is not that elegant, needs a
lot more software than the "filesystem as a database vision" and has of course
poor performance by design compared to a direct solution like Reiser4.

And even FUSE is higly demanded as you can see e.g. with the KIO-Slaves of KDE
where the filesystem view is implemented even in a higher level (to my
knowledge KIO only exists as KDE needed a solution that works right now and
not after many flames and discussions about a system like FUSE).

So I personally see FUSE and Reiser4 somewhat related and beeing objected by
some people at LKML beside implementational problems by the same reasons of
"traditional" thinking.

My personal vision would be using FUSE as a transition tool for changing
existing structures back to the file system style and for mounting
non-traditional remote database structures (as SSH/SFTP or IMAP like it is
already done by the KIO-system in KDE) and Reiser4-plugins for sophisticated
structures that enable direct fast local database access without the need of
additional software.

Both ideas would be the killer feature of Linux desktops if used in
applications on larger scale.

So I wish you very much luck with getting this finally into the Linux 2.6 main
kernel as this software works right now and is needed right now. There is
always room for later tuning in which kernel layer a specific function has to
be...

Have fun,
Daniel Arnold