lkml.org 
[lkml]   [2004]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: silent semantic changes with reiser4
Date
From
Hans Reiser <reiser@namesys.com> said:
> Andrew Morton wrote:

[...]

> > The fact that one filesystem will offer features which other
> > filesystems do not and cannot offer makes me queasy for some reason.

Not me. As long as it is clearly experimental stuff that can be removed at
the head hacker's whim, that is. 2.7 material.

> Andrew, we need to compete with WinFS and Dominic Giampaolo's filesystem
> for Apple,

Says who?

> and that means we need to put search engine and database
> functionality into the filesystem.

Please don't. Unix works and is extremely popular because it _doesn't_ try
to be smart (policy vs mechanism distinction, simple abstractions that can
be combined endlessly). If you add this to the filesystems, you either redo
_all_ userland to understand _one_ particular way of doing "smart things"
(which will turn out to be almost exactly the dumbest possible for some
uses, and then you are stuck), or get lots of shards from broken apps (and
users, and sysadmins).

> It takes 11 years of serious
> research to build a clean storage layer able to handle doing that.

Great! Build an experimental OS showing how to use it, and through that see
if the ideas hold any water _in real, day-to-day, down-to-earth, practice_.

> Reiser4 has done that, finally. None of the other Linux filesystems
> have.

How come nobody before you in the almost 30 years of Unix has ever seen the
need for this indispensable feature?

> The next major release of ReiserFS is going to be bursting with
> semantic enhancements, because the prerequisites for them are in place
> now. None of the other Linux filesystems have those prerequisites.

To me that would mean that ReiserFS has no place in Linux.

> They won't be able to keep up with the semantic enhancements. This
> metafiles and file-directories stuff is actually fairly trivial stuff.

Maybe. But the question of it being of any use aren't trivially answered
"yes". My gut feeling is that the answer is a resounding "no", but that's
just me. Direcories are directories, if you want to ship directory-like
stuff around, use directories (or tarfiles, or whatever). Just look what
happened to the much, much easier stuff of splitting SUID/SGID into
capabilities: Nothing at all whatsoever, because they have no decent place
to stay in the hallowed Unix APIs. Sure, Linux is now large enough to be
able to _define_ APIs to follow, but even so it isn't at all easy to do so.

> Look guys, in 1993 I anticipated the battle would be here, and I build
> the foundation for a defensive tower right at the spot MS and Apple are
> now maneuvering towards.

Why place a protective tower around the pit into which they are trying
desperately to throw themselves? ;-)

> Help me get the next level on the tower before
> they get here. It is one hell of a foundation, they won't be able to
> shake it, their trees are not as powerful. Don't move reiser4 into vfs,
> use reiser4 as the vfs. Don't write filesystems, write file plugins and
> disk format plugins and all the other kinds of plugins, and you won't be
> missing any expressive power that you really want....

Better write libraries handling whatever weird format you have in mind for
each use. Even applications. I don't expect to be able to use emacs to edit
a JPEG or PostgreSQL database. Neither do I expect gimp to be able to edit
a poem. The current trend (which I heartily agree with) is to take stuff
_out_ of the kernel (for flexibility, access, development ease, even
performance).
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:05    [from the cache]
©2003-2011 Jasper Spaans