|| ||Linus Torvalds <torvalds-AT-osdl.org>|
|| ||Horst von Brand <vonbrand-AT-inf.utfsm.cl>|
|| ||Re: silent semantic changes with reiser4|
|| ||Tue, 31 Aug 2004 13:05:40 -0700 (PDT)|
|| ||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>,
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).
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
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
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
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
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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
to post comments)