> Instead, we're much better off designing a high-level API (implemented
> using a replaceable shared library) for storing and retrieving metadata
> information (and a common metadata format which both KDE and GNOME
> share!!!), and then having a shared library which implements the storage
> of said metadata information via some non-kernel, non-FS means. If
> later somoene wants to extend the filesystem to provide storing resource
> forks, fine we can replace the shared library with one that makes the
> non-standard, non-POSIX API calls, but I really don't see any value in
> storing such information in this fashion over any one of the myriad of
> schemes which don't require filesystem support.
This is the structured storage approach. It is hideous. It creates
non-symmetric semantics, and it inevitably results in lower performance
implementations because it layers one storage allocation system on top of another.
Just look at what happened when MS did this.
What do you get from your API that you can't get a higher performance
solution for in ReiserFS? Even just the solution of a directory called
filename.forks is far superior to any structured storage style solution,
and filename.forks would not require any changes to namei().
As for kernel bloat, what kernel bloat? It won't add anything significant
to ReiserFS or the kernel to handle this.
Ted, you have written a nice filesystem that just isn't designed for this
need. You don't want to rewrite it from scratch to handle this issue
efficiently. ReiserFS was designed for this need and any modifications
would be trivial to none. Don't ask glibc to take on the role of namei(), that
is just so wrong. Structured Storage is such bloated code, such a bloated API,
please remember that anytime you add an API you add to code complexity.
What do we need with one way of using objects that happen to be metadata
and another way of using objects that are data? That means twice the coding!
And why shouldn't I be able to do a cp filename.forks/icon filename2.forks/icon
to copy the icon from one file to another?
You would bloat every user application with the need to understand and employ
a new glibc API so that you can avoid complicating your FS, and force the
application developers to write that API so that you won't have to, and the result
will be unnecessarily non-symmetric code that is lower performance.
Perhaps I am being unfair in assuming that it would resemble what MS did but.....
Let's just use directories, and make them efficient enough that it works.
I can tell you why Apple didn't use directories. It was because the FS group
just didn't give a damn about the needs of the other OS developers,
and a solution had to be developed for their needs that didn't involve making
the FS group change their precious code. I discussed it with both sides.
I listened the filesystem guys explain how disks were cheap, and the
application developers didn't really understand their own needs, and.....
I'll bet you dollars to donuts it went exactly the same way at MS,
and the needs were met by writing storage system code that didn't require
the help of those FS guys who didn't care, that layered ontop of the FS,
that bloated the code, that slowed performance, that reduced code symmetry,.....
I am repeating, sorry.
I hope Vladimir finishes reiserfsck this week, I think reiserfs is ready to ship
something usable when he does finish it. He is working hard on it. While I wait I am chasing down
something that might improve our performance substantially if I get lucky
I am trying aggressively writing inode updates to buffers while the buffers
holding the stat data are still in memory. (Vladimir got me going on this.....)
Yura is trying to improve read performance by patiently
examining the read code, profiling it, and reorganizing it based on his
measurements. By my interpretation, his measurements suggest that our
read code should be susceptible to improvement, so I predict that he
will have some success.
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.altern.org/andrebalsa/doc/lkml-faq.html