User: Password:
|
|
Subscribe / Log in / New account

Re: silent semantic changes with reiser4

From:  Linus Torvalds <torvalds-AT-osdl.org>
To:  Horst von Brand <vonbrand-AT-inf.utfsm.cl>
Subject:  Re: silent semantic changes with reiser4
Date:  Tue, 31 Aug 2004 13:05:40 -0700 (PDT)
Cc:  Pavel Machek <pavel-AT-ucw.cz>, David Masover <ninja-AT-slaphack.com>, Jamie Lokier <jamie-AT-shareable.org>, Chris Wedgwood <cw-AT-f00f.org>, viro-AT-parcelfarce.linux.theplanet.co.uk, Christoph Hellwig <hch-AT-lst.de>, Hans Reiser <reiser-AT-namesys.com>, linux-fsdevel-AT-vger.kernel.org, linux-kernel-AT-vger.kernel.org, Alexander Lyamin aka FLX <flx-AT-namesys.com>, ReiserFS List <reiserfs-list-AT-namesys.com>



On Tue, 31 Aug 2004, Horst von Brand wrote:
> 
> You do need extra tools anyway, placing them in the kernel is cheating (and
> absolutely pointless, IMHO).

I agree.

There's no point to having the kernel export information that is already 
inherent in the main stream.

I've seen all these examples of exposing MP3 ID information as a "side 
stream", and that's TOTALLY POINTLESS! The information is already there, 
it's in a standard format, and exporting it as a stream buys you 
absolutely nothing.

Where named attributes make sense is when they are _independent_ data.  
Data that is only tangentially related to the main stream itself, and
which the main stream _cannot_ encompass because of some real technical
issue.

In a graphical environment, the "icon" stream is a good example of this.  
It literally has _nothing_ to do with the data in the main stream. The
only linkage is a totally non-technical one, where the user wanted to
associate a secondary stream with the main stream _without_ altering the
main one. THAT is where named streams make sense.

But if you want to look at one particular file inside a tar-file, do so in 
user space. There are zero advantages to exposing it as a side-stream, and 
there are absolutely _tons_ of disadvantages.

In short, named streams only make sense if:
 - they are tied to the file some way that is _independent_ of the file 
   contents (since if it's dependent on the file contents, you're just a 
   ton better off regenerating it with a caching server)
 - there are serious reasons to keep the lookup synchronized (since if 
   there isn't such a reason, you're just better off with a separate 
   shadow tree in user space)

And realize that the "separate shadow tree" actually works very well.  
That's how version control systems like CVS have always worked. It's
certainly how you can make icon information work too. If you use a tool
for accessing the data, the tool can maintain coherency and you'll never
care about the side stream.

Which means that normally we really don't _want_ named streams. In 99% of
all cases we can use equally good - and _much_ simpler - tool-based
solutions.

Which means that the only _real_ technical issue for supporting named
streams really ends up being things like samba, which want named streams
just because the work they do fundamentally is about them, for externally
dictated reasons. Doing named streams for any other reason is likely just
being stupid.

Once you do decide that you have to do named streams, you might then 
decide to use them for convenient things like icons. But it should very 
much be a secondary issue at that point.

		Linus
-
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/


(Log in to post comments)


Copyright © 2004, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds