linux-kernel - Re: Question about Reiser4

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1177483176.3315.32.camel@bats.omnifarious.org>
Date:	Tue, 24 Apr 2007 23:39:36 -0700
From:	"Eric M. Hopper" <hopper@...ifarious.org>
To:	Theodore Tso <tytso@....edu>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Question about Reiser4

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@...ifarious.org  http://www.omnifarious.org/~hopper/)

Download attachment "signature.asc" of type "application/pgp-signature" (186 bytes)