lkml.org 
[lkml]   [1999]   [Jun]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: (reiserfs) Re: File systems are semantically impoverished compared to database and keyword systems: it is time to change!
In <000e01bebdfa$ff79ab30$04cca8c0@slamsoftware.com> Acy James Stapp (astapp@austin.rr.com) wrote:
> 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.

Why do we need it ? We can use some simple convention: "\my_document" is not
directory but albod "my_document" while "my_document" is just plain directory.
There are still exists some minor possibility of clash so additional check
should be added (for .albod subdirectory in directory with name started with
"\") but in 99.999% cases you'll not need additional directory access.

BTW about directories: why I cann't add cool icon to directory ? May be we
need some way to have directory-with-metadata ? "*my_folder" perhaps ?

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

We REALLY need BOTH 100% user level implementation (first) and mixed mode
implementation (where time-critical operations are pulled in kernel).
Without 100% user-level portable implementation multifork documents will not
be adopted by GNOME/KDE and without application all cool stuff in kernel is
useless. On other hand I'm pretty sure that once we'll have user-level
implementation in place we'll find enough reasons to pull some parts in
kernel for speed.

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

Yes. It's great acronym. But where this discussion must continue ? It does
not belond to linux-kernel anymore but where it belonds to ? There are quite
a few things must be resolved (who and when will reassemble blob received via
http/ftp/whatever? do we need something like ncd?)...



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