lkml.org 
[lkml]   [2004]   [Aug]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: silent semantic changes with reiser4
> 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.

There are two things you are saying in the same sentence here. One I
do not agree with. There is point to export information from the
main stream to secondary file streams. Just it doesn't have to be
done by the kernel.

Just do not limit things to a few defined types of things that can
be stored in a stream. IMHO a file stream should be able to contain
just about anything the user wishes. That said, the kernel should
not have to know about the contents.

> 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.

True. But this is the case for this specific example. I have stated
previously about what I think would be legitimate uses as examples.
Of course these apply to me and what I work with. One of the
examples were to add streams that contained descriptions or
keywords.

> 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.

The tar archive support seem (is) to be useless because tar is also
so supported and implemented in every type of application out there.
It is also easy to script and otherwise work with.

But the idea to be able to extend the filesystem to show/represent
data as file streams and meta directores is very good.

Someone might come up with an idea to allow browsing and changing of
data inside XML files. Of course this may already be done with sed
and other tools.

> 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.

Just that with shadow trees (I assume they are stored simply in
another folder beside the file) you won't be able to "cp filea
/mnt/backup" and keep the extra stuff.

Sure icons could also easily be stores as file.icon, just like on
the Amiga :). It just isn't as nice.

> 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.

I doubt it would be stupid. Perhaps today just not needed for many
things.

> 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.

I think we focus to much on the actual contents of these streams. Do
we really have to know what will in the future be stored inside
these streams?

For example. Applications may use file streams for locking instead
of having a .lock file. The future isn't known, and we shouldn't try
to limit what we can put in the streams. You said 99% of the uses
won't need them. True. The same is with xattr, ACLs and so many
other things.

Even if 0.1% of the users today would use it I think we should have
the support for named streams.

~S

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

\
 
 \ /
  Last update: 2005-03-22 14:05    [W:1.475 / U:0.544 seconds]
©2003-2011 Jasper Spaans. Advertise on this site