[lkml]   [1999]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: (reiserfs) Re: File systems are semantically impoverished compared to database and keyword systems: it is time to change!
    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
    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 -->
    [path-outside-albod]/albodname/.albod/default --> ../albodname.txt

    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
    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
    [path-outside-albod]/.albodfilters/albodname -->
    Or even
    [path-outside-albod]/.albod/albodname/filter -->
    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 /
    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
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:52    [W:0.021 / U:104.904 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site