[lkml]   [1998]   [Sep]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Implementing Meta File information in Linux

    On Mon, 31 Aug 1998 15:08:34 -0700, Hans Reiser <> said:

    > With regards to namei() in general:

    > I think that what you are failing to realize is that it is possible to
    > change namei() while retaining upward compatibility.

    > I have a complete set of semantics designed for namei() which are
    > based on what russians would call set-theoretic database theory.
    > These semantics give you everything that a keyword system or a
    > database can give you but with greater generality and abstraction.

    That's fine. I have no objection to that, but that's not really what
    the discussion about forks started off as.

    The issue was about adding extra streams to a file in a way which does
    not change the visible contents of the file as seen by a normal open().
    It's not an issue of keeping the "main" contents of the file in a
    subfork; it's a question of adding subforks _without_ disturbing the
    main contents. That, by definition, changes the semantics of namei():
    you no longer get the whole contents of the file back when you do an
    open() and read().

    That is the crux of my objections. If we add such hidden information,
    then all our current tools (NFS, tar, cp, mv etc) fail. NFS in
    particular is a killer: by adding functionality to the fs which cannot
    be encoded in the standard NFS protocol, we lose the ability to share
    these files.

    If we want to add tagged information to a file, far better to do it via
    a dot directory. Keep the problem in user space where it belongs. Any
    extra efficiency that the fs has to offer will still be realised by such
    a mechanism.

    Only where the kernel *has* to be involved (such as for security issues)
    can we justify adding the fork in the kernel. That alone justifies
    having fork capability in the kernel. It does not justify adding a
    generic fork API to the kernel; far better to have a separate ACL API
    and let each filesystem deal with it in the most appropriate manner.


    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:44    [W:0.020 / U:40.840 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site