[lkml]   [2004]   [Aug]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: silent semantic changes with reiser4

    Hans> My reason is that the things that distinguish between objects
    Hans> should be the names, not the choice of system call. The reason
    Hans> for this is that it improves closure and namespace unification
    Hans> to do so, because it allows all the objects to be accessed
    Hans> within the same namespace.

    So who decides what the names mean in a specific context? How do we
    get consistency across applications? In the Apple and MicroSoft
    cases, it's a single company which sets the standards for the names of
    the streams and what they mean. I have no knowledge of how Sun is
    doing this. I don't see us setting up a single naming authority and
    enforcement mechanism.

    I went and read the Pike paper on namespaces which Hans quotes much
    earlier in this thread, and I think it isn't applicable to this
    thread. In the paper Pike compares the MVS, VMS, DOS and Unix name
    spaces for disk layouts. It's an interesting paper, though a bit
    dated since it's 20 years old. The concepts are good, but the
    examples aren't any more. How many Unix systems today have
    /n/faces/... to link email addresses to digitized images of people

    The big point of this paper though was to make the syntax simple, and
    the semantics clear and unambiguous. For example, they point out how
    the "Cedar" file system added in VMS style version numbers to
    filenames with the syntax "<name>!<version>" and they pointedly ask
    what does "/usr/rob!3/bin/cat-v mean? Which I think just points out
    that the syntax of streams (metas) needs be carefully thought out, and
    how that syntax implies various semantics.

    Lots of people keep asking for ACLs, but time and time again people
    point out that while the Unix permission model isn't as flexible, it
    is _simpler_ and easier to keep track of.

    As an example of complexity, just keeping track of our /etc/sudoers
    file with all the users, hosts and commands that can be defined is a
    huge hassle. You pretty much need to have a 'lint' style program to
    do the consistency checking.

    Hans> Yes, it can be useful to allow a namespace to exclude some
    Hans> objects, but that exclusion should not be mandated.

    Conversely, should a namespace *require* that objects always be there?
    What happens when I mount an NFS filesystem onto a Resierfs4 tree?
    How does the user/apps determine when the semantics of the underlying
    namespace have changed?

    Hans> If you want to exclude, you should cd or chroot to
    Hans> /proc/nopseudos and find a view of the filesystem that excludes
    Hans> metas, or mount with -nopseuodos.

    Hans> Do you see why I say this? I can say a lot more about the
    Hans> damage of fragmenting namespaces into multiple apis.... Why look
    Hans> at xattrs....;-)

    I think one of the advantages of the xattrs is that the core namespace
    doesn't change, nor do the semantics. They are layered on top and can
    be explicitly looked at.

    A real life problem of namespaces is Network Appliance Filers. If you
    have a filer with both NFS and CIFS exports, it will nicely manage the
    CIFS ACLs in harmony (for some level you determine) with the NFS and
    Unix permissions. But to backup that data, and to store that
    information, you need to use either their 'dump' tool or NDMP. If you
    NFS mount the filesystem to your backup host and then use a simple tar
    to back it up, you lose the information since that window you use to
    look into the namespace is restricted.

    It's a gotcha. Until we can (or maybe computing in general) come up
    with a new namespace paradym which we can all agree to, this is going
    to be a big issue.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:05    [W:0.025 / U:30.768 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site