public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Masover <ninja@slaphack.com>
To: Theodore Tso <tytso@mit.edu>, David Masover <ninja@slaphack.com>,
	"Vladimir V. Saveliev" <vs@namesys.com>,
	Andrew Morton <akpm@osdl.org>,
	vda.linux@googlemail.com, linux-kernel@vger.kernel.org,
	Reiserfs-List@namesys.com
Subject: Re: reiser4: maybe just fix bugs?
Date: Fri, 04 Aug 2006 17:09:30 -0400	[thread overview]
Message-ID: <44D3B78A.8000900@slaphack.com> (raw)
In-Reply-To: <20060803074651.GA27835@thunk.org>

Theodore Tso wrote:
> On Tue, Aug 01, 2006 at 11:55:57AM -0500, David Masover wrote:
>> If I understand it right, the original Reiser4 model of file metadata is 
>> the file-as-directory stuff that caused such a furor the last big push 
>> for inclusion (search for "Silent semantic changes in Reiser4"):
> 
> The furor was caused by concerns Al Viro expressed about
> locking/deadlock issues that reiser4 introduced.  

Which, I believe, was about file-as-dir.  Which also had problems with 
things like directory loops.  That's sort of a disk space memory leak.

> The bigger issue with xattr support is two-fold.  First of all, there
> are the progams that are expecting the existing extended attribute
> interface,

Yeah...

> More importantly are the system-level extended attributes, such as
> those used by SELINUX, which by definition are not supposed to be
> visible to the user at all,

I don't see why either of these are issues.  The SELINUX stuff can be a 
plugin which doesn't necessarily have a user-level interface. 
Cryptocompress, for instance, exists independent of its user-level 
interface (probably the file-as-dir stuff), and will probably be 
implemented in some sort of stable form as a system-wide default for new 
files.

So, certainly metadata (xattrs) as a plugin could be implemented with no 
UI at all, or any given UI.

... Anyway, I still see no reason why these cannot be implemented in 
Reiser4, other than the possibility that if it uses "plugins", I 
guarantee that at least one or two people will hate the implementation 
for that reason alone.

> Not supporting xattrs means that those distro's that use SELINUX by
> default (i.e., RHEL, Fedora, etc.) won't want to use reiser4, because
> SELINUX won't work on reiser4 filesytstems.

Right.  So they will be implemented, eventually.

> Whether or not Hans cares about this is up to him....

He does, or he should.  Reiser4 needs every bit of acceptance it can get 
right now, as long as it can get them without compromising its goals or 
philosophy.  Extended attributes only compromise these because it 
provides less incentive to learn any other metadata interface that 
Reiser4 provides.  But that's irrelevant if Reiser4 doesn't gain enough 
acceptance due to lack of xattr support, anything it has will be 
irrelevant anyway.

So just as we provide the standard interface to Unix permissions (even 
though we intend to implement things like acls and views, and even 
though there was a file/.pseudo/rwx interface), we should provide the 
standard xattr interface, and the standard direct IO interface, and 
anything else that's practical.  Be a good, standard filesystem first, 
and an innovative filesystem second.

  reply	other threads:[~2006-08-04 21:09 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-31  9:26 reiser4: maybe just fix bugs? Denis Vlasenko
2006-07-31 12:38 ` Adrian Bunk
2006-07-31 16:17 ` Horst H. von Brand
2006-07-31 20:06   ` Denis Vlasenko
2006-08-01 15:22     ` Theodore Tso
2006-08-01  2:30 ` Hans Reiser
2006-08-01 10:37   ` Pavel Machek
2006-08-01 13:59     ` Scott J. Harmon
2006-08-02  6:22       ` Jan Engelhardt
2006-08-02 19:53   ` Denis Vlasenko
2006-08-01  8:31 ` Andrew Morton
2006-08-01  2:18   ` Hans Reiser
2006-08-01 11:24     ` Vladimir V. Saveliev
2006-08-01 14:33       ` Andrew Morton
2006-08-01 15:07         ` Vladimir V. Saveliev
2006-08-01 16:55           ` David Masover
2006-08-01 19:26             ` Nate Diller
2006-08-02  3:54               ` David Masover
2006-08-03  7:46             ` Theodore Tso
2006-08-04 21:09               ` David Masover [this message]
2006-08-01 19:14         ` Nate Diller
2006-08-01 11:43   ` Christoph Hellwig
2006-08-01 11:52   ` Nick Piggin
2006-08-01 14:54     ` Andrew Morton
2006-08-01 19:32   ` Andi Kleen

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=44D3B78A.8000900@slaphack.com \
    --to=ninja@slaphack.com \
    --cc=Reiserfs-List@namesys.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tytso@mit.edu \
    --cc=vda.linux@googlemail.com \
    --cc=vs@namesys.com \
    /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