Re: Question about Reiser4

[Eric M. Hopper]

On Mon, 2007-04-23 at 20:19 -0400, Theodore Tso wrote:
> Sure, but Hans wants to change /etc/inetd.conf into /etc/inetd.conf.d,
> where you have: /etc/inetd.conf.d/telnet/port,
> /etc/inetd.conf.d/telnet/protocol, /etc/inetd.conf.d/telnet/wait,
> /etc/inetd.conf.d/telnet/userid, /etc/inetd.conf.d/telnet/daemon,
> etc. for each individual line in /etc/inetd.conf.  (And where each
> file might only contains 2-4 characters each: i.e., "23", "tcp",
> "root", etc.)

One interesting thing is that /proc already does this.  You can often
generate interesting behavior by writing something into a file in /proc.
If the config file for inetd.conf.d/tellnet/port changed, inetd could
automatically reconfigure that service, and just that service.  No more
re-reading a config file and trying to figure out what changed, you are
notified as soon as it changes on the FS by the FS change detection code
already in place.

It seems to me that being able to be more transparent about how your
on-disk data structures are structured has many interesting implications
and possible advantages.  It should be able to be explored by the wider
sphere of app developers.  Perhaps you are right, and the performance
implications of making all those system calls will be too much.  Or
maybe there's some good way nobody has thought of yet to handle that
problem.  But until the idea can be experimented on and played with,
nobody will know.

And realistically for that to happen Reiser4 has to be available as an
option in the kernels shipped by the major distributions.  And this in
turn requires that it be part of the mainline kernel.

Also, regardless of whether tiny files and on-disk datastructure
transparency exist, I think filesystems should also support ACID.  I
would, in fact, be much happier with ACID support at the filesystem
level than on-disk datastructure transparency.  And while Reiser4
doesn't do this, as I understand it (and I might be wrong) there is some
limited support for transactions built into it beyond simple lock
handling.

-- 
Eric Hopper (hopper@xxxxxxxxxxxxxxx  http://www.omnifarious.org/~hopper/)

Attachment: signature.asc
Description: This is a digitally signed message part