lkml.org 
[lkml]   [1999]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: (reiserfs) Re: File systems are semantically impoverished compared to database and keyword systems: it is time to change!
Date
Christopher B. Browne wrote:

| Theodore T'so wrote:
| > So, here's a quick back-of-the-envelope design for a completely
| > user-space solution for folks who have been asking for multi-fork files.
| > .....
| > extra extensions to the libc, which might be considered kludgy, I
| > believe it is no worse than the Microsoft NTFS-style "reparse points"
| > suggestion which was offered to the kernel list in the last day or so.
|
| Some of what has taken place has been "pie in the sky" thinking, without
| a down-to-earth enumeration of the set of constraints that will be
| expected. Lots of "cool ideas," but no real requirements analysis.

"Reparse points" or filters could be even more easily (and perhaps
more fruitfully) implemented as part of the standard library. The major
difference
would be the location of the metadata: the filter, the sequence, and
perhaps a default presentation. In a user space libc implementation, these
would necessarily be stored as regular files in the filesystem.
The most obvious solution is
[path-outside-albod]/albodname/.albod/filter -->
/lib/modules/fs/albodfilter.o
[path-outside-albod]/albodname/.albod/default --> ../albodname.txt
[path-outside-albod]/albodname/.albod/order
etc.

This introduces another directory access on every open (to
see if a directory has an .albod entry and hence should be treated
as a file) even for non-albod aware apps. This might be a noticeable
performance hit for certain apps.

One big advantage is that this doesn't introduce a new namespace.
A kernel mode implementation could be made to provide services
through the .albod/ interface in order to preserve transparency between
user-mode and kernel-mode implementations.

Other advantages of a user-space implementation are fewer
security concerns and portability to other OSs.

However, the above directory structure wouldn't allow a file to impersonate
a
directory. In order to do so, the albod metadata would have to exist
in some place other than a subdirectory of the albod (since the albod is a
file).
i.e.
[path-outside-albod]/.albodfilters/albodname -->
/lib/modules/fs/albodfilter.o
Or even
[path-outside-albod]/.albod/albodname/filter -->
/lib/modules/fs/albodfilter.o
Each has it's advantages and disadvantages.

Oh, and I think "albod" is a great acronym. I'm going to start using it
in my daily conversations.
--
Acy Stapp / astapp@austin.rr.com
Now Playing: "Sheila", Morphine, [Cure For Pain]



-
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.038 / U:1.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site