lkml.org 
[lkml]   [1999]   [Jun]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: (reiserfs) Re: Summary of how linux can best avoid the need for streams
Date
Richard Gooch writes:
> Hans Reiser writes:
>> Richard Gooch writes:
>>> Hans Reiser writes:
>>>> Richard Gooch writes:
>>>>> Hans Reiser writes:
>>>>>>
>>>>>> I am not saying put an FS into a file, I am saying make the filesystem
>>>>>> effective enough that nobody needs to create things like structured
>>>>>> storage. Given that as a goal, what is needed?
>>>>>
>>>>> I don't even concede this goal. In some cases "structured storage"
>>>>> inside a file is quite reasonable and efficient.

You have a 1.5 GB file composed of 3 evenly sized parts and a header.
The middle part grows by one byte. Eh, what now?

> I advocate putting albods/data forks/streams/what-have-you into
> separate files in a directory, and making no changes to the kernel or
> libc. That means the default behaviour of the kernel, libc and system
> utilities is that a directory-based albod is just another directory.

In other words, scratch this whole idea. Suffer your choice of
inefficiency or user-hostility.

> Other (optional) behaviour can be added on top of this.

This can not be. If you really think that random user-space software
developers will agree on a way to use directories as documents...
It isn't enough to have a few GUI apps. Users will be confused by
the inconsistent treatment.

>>> No, I didn't say that. What I'm saying is that the most common user
>>> who wants to see albods as atomic is sitting behind a GUI.

When I write code, I want a way to get at the inside.
When I do other things, I don't want to bother with such details.

>>> Command-line users who want to see albods as atomic can use some
>>> special tools, or perhaps switches to existing tools.

Command-line users who want to see the parts can use special tools.
$ albod -x 80A8C452 ~/foo.doc > a.png

>> I don't understand you, except that I think you know how you have
>> seen it done, and think that the way it has been done must be the
>> right way.
>
> You're being offensive.

I'd say you are afraid of change. When the topic isn't devfs... :-/

> If you stuff around with the kernel/libc, you make it hard/impossible
> for people to see the raw components (real files in real directories).
> I can't stress enough how wrong that would be.

What use are the raw components? They won't be in any file format
that you would normally use. They may be headerless raw image data,
binary markup language, binary data structures, etc.

Since you need a special tool to create plain text anyway, you
might as well have that tool use the sub-file extraction API.

>>> Sometimes, you really want to get in at the raw interface and play
>>> with things.

This isn't VxWorks. You can't do system calls on the command line,
and I don't see much demand for that feature either.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.114 / U:0.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site