Re: NFS comments


Marshall Rose (mrose@nrtc-gremlin.arpa)
Sun, 21 Dec 86 10:01:45 -0800


    Well let me try to answer that. I've only read the spec twice and
    don't have it here in from of me but here goes...

    FTAM is based on the notion of a "virtual filestore" (sound
    familiar, huh?) The filestore consists of zero or more files, each
    with an unambiguous name. Each file has a set of attributes (of
    which filename is one) and some contents. The attributes have the
    usual permission stuff along with a description of the kind of
    information the file contains (e.g., iso646 ascii, octets, bits),
    and a description of the access discipline (my term) for the file.
    The contents is a binary tree. Each node in the tree contains

        - node attributes:
                node name
                length of arc back to parent
                a flag saying whether data is attached to this node
        - attached data (if any)
        - a list of children

    Now, there are a couple of ways that you can implement a UNIX-style
    regular file. The simplest is to have just the root node with the
    entire file contents as the attached data (as an octet string) and
    no children. In this case, the access discipline is rather
    inconsequential, since you can only get at one data element at a
    time and there is only one to choose from.

    Alternately, for a file like /etc/passwd, you might have a root node
    with no data, and a child for each line in the file. The access
    discipline would allow you to specify any child element you want
    when you wanted to read or write.

    There are in the spec, several document types and access disciplines
    listed with pre-defined meanings. Others can be chosen via
    "bi-lateral" agreement. In the NBS OSI Implementor's Workshop
    Agreements, they have defined a new document type called "directory"
    in which the nodes are, you guessed it, file names. Assuming you
    had an FTAM server which supported that document type, an FTAM
    client could do the DIR and NLST commands that we've all become so
    attached to.

    So to answer your question: FTAM imposes on everyone the same
    fairly general file model. Each FTAM server consists of a protocol
    engine for FTAM and a localFS-virtualFS engine. For UNIX-like
    systems, going between the two is rather restricted unless you want
    to put a lot of smarts in your code (at which true UNIX-ites would
    gasp, I'm sure people are reeling at my /etc/passwd example!). In
    this case, the question of "is it ascii or is it octet-aligned or is
    it bit-aligned" is something the localFS-virtualFS engine for UNIX
    would have to answer. Now of course, if you had something like
    DEC's RMS in your filesystem, FTAM makes more sense as there is a
    closer match between the local and virtual filestores.

    It is important in all of this however, to remember what OSI is: a
    method for tying together dissimilar systems. This is done by
    choosing a sufficiently general model which is (hopefully) a
    superset of all existing systems, and then letting people code
    local2virtual engines at the network boundary.

    With respect to RPC, there are such notions in OSI. My favorite is
    called ROS (Remote Operations Service) which is a fairly simple
    invoke-result, invoke-error protocol with provisions to support
    "once-only" execution of operations. FTAM is not meant as a
    competitor to ROS (and quite frankly, had *I* designed FTAM, I would
    have put FTAM on top of ROS), but is trying to solve a different
    problem, which perhaps has overlap for certain applications.

/mtr



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:37:14 GMT