Re: I discussed reading directories as files with jra, Stallman, and loic

root (reiser@ceic.com)
Tue, 22 Jun 1999 11:26:56 +0000 (/etc/localtime)

Pavel Machek writes:
> Hi!
>
> > It was two separate conversations, but they both go together. I ask
> > that they correct me if I unfairly summarize their words.
> >
> > Jeremy wants in the FS what he can get with Microsoft streams and
> > Macintosh forks. That is, he wants to be able to name an object, and
> > read it, and get something, and he wants to be able to add something
> > that goes into that object, and stays with it when the object gets moved.
> > He wants this because he is a Samba author, and it will make his life a
> > lot easier to have it when Windows 2000 comes out.
>
> Oops. Should not he do it himself? This will make samba non-portable
> and what is worse samba will not run on ext2.

Well, actually, he first wanted XFS style resource forks, and I talked
him into this.

We have to innovate in FS design. For too long FS semantics design has
stagnated.

>
> > Next files need to be able to inherit stat data, so that a file can
> > share its modification time with its parent directory, so that modifying
> > the file changes the mod time on the directory.
>
> Is sharing modtime this critical? I can see samba asking for both
> times and then just exporting the newer one :-).

Yuck. That is an ugly hack. Inheritance is worth doing for reasons other
than this.

>
> > Now let's skip ahead to my conversation with rms and loic@ceic.com which
> > came after talking with Jeremy..
> >
> > This time we discussed how you might read and edit the contents of a
> > directory as an aggregation within one buffer. The examples were
> > editing /etc/passwd and /etc/services within emacs, with passwd and
> > services converted into directories. Imagine that passwd is converted
> > into a directory, with each line being a separate file, and each file
> > (line) having a separate modification time. Clearly something useful.
> > Reading it is easy, you have a read on the directory return the
> > concatenation of the files.
>
> This should be done in userspace. Editing /etc/passwd is certainly not
> performance critical so podfuk is just the right
> answer. (http://atrey.karlin.mff.cuni.cz/~pavel/podfuk/podfuk.html).
>
> Pavel

I am not going to avoid innovating in the kernel just so that there is
more functionality for your FS to implement in user space.

Just because /etc/passwd is not performance critical does not mean that
other applications aren't performance bound.

As for the general tone of your email, let me just say that I differ
from other FS designers in that I actually think that the features
application developers ask for are normally motivated by real needs, and
that while I may distill their needs a little for them, I do believe in
listening to them.

Besides, the feature is going to be neat....:-)

Hans

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