From: "Eric M. Hopper" <hopper@omnifarious.org>
To: Theodore Tso <tytso@mit.edu>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Question about Reiser4
Date: Tue, 24 Apr 2007 23:39:36 -0700 [thread overview]
Message-ID: <1177483176.3315.32.camel@bats.omnifarious.org> (raw)
In-Reply-To: <20070424001934.GC1663@thunk.org>
[-- Attachment #1: Type: text/plain, Size: 2157 bytes --]
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@omnifarious.org http://www.omnifarious.org/~hopper/)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 185 bytes --]
next prev parent reply other threads:[~2007-04-25 6:39 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-23 2:00 Eric Hopper
2007-04-23 2:31 ` Lee Revell
2007-04-23 3:56 ` Rik van Riel
2007-04-23 3:56 ` William Heimbigner
2007-04-23 5:47 ` Rik van Riel
2007-04-23 5:57 ` William Heimbigner
2007-04-23 6:07 ` Rik van Riel
2007-04-23 6:14 ` William Heimbigner
2007-04-23 6:20 ` Rik van Riel
2007-04-23 6:42 ` William Heimbigner
2007-04-23 8:04 ` Andrew Morton
2007-04-23 11:31 ` l.genoni
2007-04-23 13:52 ` Eric Hopper
2007-04-23 17:40 ` Andrew Morton
2007-04-23 18:36 ` Miguel Ojeda
2007-04-23 19:05 ` Andi Kleen
2007-04-23 22:56 ` Theodore Tso
2007-04-23 23:53 ` H. Peter Anvin
2007-04-24 0:14 ` Neil Brown
2007-04-24 0:21 ` H. Peter Anvin
2007-04-24 13:30 ` Jan Engelhardt
2007-04-24 0:19 ` Theodore Tso
2007-04-24 0:31 ` H. Peter Anvin
2007-04-24 1:17 ` Theodore Tso
2007-04-24 11:15 ` Denis Vlasenko
2007-04-25 6:39 ` Eric M. Hopper [this message]
2007-04-25 14:45 ` lkml777
2007-04-23 6:14 ` Jeff Chua
[not found] <20070423111939.c876c9cc.akpm@linux-foundation.org>
2007-04-24 14:43 ` Edward Shishkin
2007-04-24 19:39 ` Andi Kleen
2007-04-25 14:35 ` Edward Shishkin
2007-04-25 14:49 ` Jeff Chua
2007-04-25 15:06 ` lkml777
2007-04-25 15:50 ` Jeff Chua
2007-04-26 5:05 ` lkml777
2007-04-26 6:49 ` Jeff Chua
2007-04-26 5:09 ` lkml777
2007-04-26 6:48 ` Jeff Chua
2007-04-26 8:18 ` Jeff Chua
2007-04-27 7:16 ` lkml777
2007-04-26 0:44 ` lkml777
2007-04-25 0:12 ` lkml777
2007-04-25 6:26 ` Eric M. Hopper
2007-04-25 15:03 ` Edward Shishkin
2007-04-26 7:47 ` lkml777
2007-04-26 7:54 ` lkml777
2007-05-02 2:39 ` lkml777
2007-05-02 4:53 ` lkml777
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1177483176.3315.32.camel@bats.omnifarious.org \
--to=hopper@omnifarious.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®