patch-2.1.75 linux/Documentation/filesystems/coda.txt

Next file: linux/Documentation/filesystems/vfat.txt
Previous file: linux/Documentation/cyrix.txt
Back to the patch index
Back to the overall index

diff -u --recursive --new-file v2.1.74/linux/Documentation/filesystems/coda.txt linux/Documentation/filesystems/coda.txt
@@ -8,103 +8,128 @@
   (version 1.0) as well as improvements we envisage.
   ______________________________________________________________________
 
-  Table of Contents:
+  Table of Contents
 
-  1.      Introduction
 
-  2.      Servicing Coda filesystem calls
 
-  3.      The message layer
 
-  3.1.    Implementation details
 
-  4.      The interface at the call level
 
-  4.1.    Data structures shared by the kernel and Venus
 
-  4.2.    The pioctl interface
 
-  4.3.    root
 
-  4.4.    lookup
 
-  4.5.    getattr
 
-  4.6.    setattr
 
-  4.7.    access
 
-  4.8.    create
 
-  4.9.    mkdir
 
-  4.10.   link
 
-  4.11.   synlink
 
-  4.12.   remove
 
-  4.13.   rmdir
 
-  4.14.   readlink
 
-  4.15.   open
 
-  4.16.   close
 
-  4.17.   ioctl
 
-  4.18.   rename
 
-  4.19.   readdir
 
-  4.20.   vget
 
-  4.21.   fsync
 
-  4.22.   inactive
 
-  4.23.   rdwr
 
-  4.24.   odymount
 
-  4.25.   ody_lookup
 
-  4.26.   ody_expand
 
-  4.27.   prefetch
 
-  4.28.   signal
 
-  5.      The minicache and downcalls
 
-  5.1.    INVALIDATE
 
-  5.2.    FLUSH
 
-  5.3.    PURGEUSER
 
-  5.4.    ZAPFILE
 
-  5.5.    ZAPDIR
 
-  5.6.    ZAPVNODE
 
-  5.7.    PURGEFID
 
-  5.8.    REPLACE
 
-  6.      Initialization and cleanup
 
-  6.1.    Requirements
+
+
+
+
+
+
+
+
+
+
+
+  1. Introduction
+
+  2. Servicing Coda filesystem calls
+
+  3. The message layer
+
+     3.1 Implementation details
+
+  4. The interface at the call level
+
+     4.1 Data structures shared by the kernel and Venus
+     4.2 The pioctl interface
+     4.3 root
+     4.4 lookup
+     4.5 getattr
+     4.6 setattr
+     4.7 access
+     4.8 create
+     4.9 mkdir
+     4.10 link
+     4.11 symlink
+     4.12 remove
+     4.13 rmdir
+     4.14 readlink
+     4.15 open
+     4.16 close
+     4.17 ioctl
+     4.18 rename
+     4.19 readdir
+     4.20 vget
+     4.21 fsync
+     4.22 inactive
+     4.23 rdwr
+     4.24 odymount
+     4.25 ody_lookup
+     4.26 ody_expand
+     4.27 prefetch
+     4.28 signal
+
+  5. The minicache and downcalls
+
+     5.1 INVALIDATE
+     5.2 FLUSH
+     5.3 PURGEUSER
+     5.4 ZAPFILE
+     5.5 ZAPDIR
+     5.6 ZAPVNODE
+     5.7 PURGEFID
+     5.8 REPLACE
+
+  6. Initialization and cleanup
+
+     6.1 Requirements
+
+
   ______________________________________________________________________
   0wpage
 
   11..  IInnttrroodduuccttiioonn
 
+
+
   A key component in the Coda Distributed File System is the cache
   manager, _V_e_n_u_s.
 
+
   When processes on a Coda enabled system access files in the Coda
   filesystem, requests are directed at the filesystem layer in the
   operating system. The operating system will communicate with Venus to
@@ -168,7 +193,7 @@
   the Coda FS layer, so the Coda FS driver must expose the VFS interface
   as applicable in the operating system. These differ very significantly
   among operating systems, but share features such as facilities to
-  read/write and create and remove object.  The Coda FS layer services
+  read/write and create and remove objects.  The Coda FS layer services
   such VFS requests in by invoking on or more well defined services
   offered by the cache manager Venus.  When the replies from Venus have
   come back to the FS driver, servicing of the VFS call continues and
@@ -176,13 +201,18 @@
   returns to the process.
 
   As a result of this design a basic interface exposed by the FS driver
-  must allow Venus to handle manage message traffic.  In particular
-  Venus must be able to retrieve and place messages and to be notified
-  of the arrival of a new message. The notification must be through a
-  mechanism which does not block Venus since Venus must attend to other
-  tasks even when no messages are waiting or being processed.
+  must allow Venus to manage message traffic.  In particular Venus must
+  be able to retrieve and place messages and to be notified of the
+  arrival of a new message. The notification must be through a mechanism
+  which does not block Venus since Venus must attend to other tasks even
+  when no messages are waiting or being processed.
+
+
+
+
 
-                       Interfaces of Coda FS Driver
+
+                     Interfaces of the Coda FS Driver
 
   Furthermore the FS layer provides for a special path of communication
   between a user process and Venus, called the pioctl interface. The
@@ -210,8 +240,10 @@
 
   33..  TThhee mmeessssaaggee llaayyeerr
 
+
+
   At the lowest level the communication between Venus and the FS driver
-  proceeds through messages.  The synchronization of between processes
+  proceeds through messages.  The synchronization between processes
   requesting Coda file service and Venus relies on blocking and waking
   up processes.  The Coda FS driver processes VFS- and pioctl-requests
   on behalf of a process P, creates messages for Venus, awaits replies
@@ -256,6 +288,7 @@
   namely when Venus calls sendmsg_to_kernel.  At this moment the Coda FS
   driver looks at the contents of the message and decides if:
 
+
   +o  the message is a reply for a suspended thread P.  If so it removes
      the message from the processing queue and marks the message as
      WRITTEN.  Finally, the FS driver unblocks P (still in the kernel
@@ -266,7 +299,7 @@
 
   +o  The message is a _d_o_w_n_c_a_l_l.  A downcall is a request from Venus to
      the FS Driver. The FS driver processes the request immediately
-     (usually a cach eviction or replacement) and when finishes
+     (usually a cache eviction or replacement) and when finishes
      sendmsg_to_kernel returns.
 
   Now P awakes and continues processing upcall.  There are some
@@ -277,6 +310,12 @@
   deallocate message structure and return.  The FS routine can proceed
   with its processing.
 
+
+
+
+
+
+
                       Sleeping and IPC arrangements
 
   In case P is woken up by a signal and not by Venus, it will first look
@@ -291,6 +330,8 @@
   extra field "handle_signals" could be added in the message structure
   to indicate points of no return have been passed.--)
 
+
+
   33..11..  IImmpplleemmeennttaattiioonn ddeettaaiillss
 
   The Unix implementation of this mechanism has been through the
@@ -312,11 +353,13 @@
 
   44..  TThhee iinntteerrffaaccee aatt tthhee ccaallll lleevveell
 
+
   This section describes the upcalls a Coda FS driver can make to Venus.
   Each of these upcalls make use of two structures: inputArgs and
   outputArgs.   In pseudo BNF form the structures take the following
   form:
 
+
   struct inputArgs {
       u_long opcode;
       u_long unique;     /* Keep multiple outstanding msgs distinct */
@@ -335,6 +378,8 @@
       <union "out" of call dependent parts of inputArgs>
   };
 
+
+
   Before going on let us elucidate the role of the various fields. The
   inputArgs start with the opcode which defines the type of service
   requested from Venus. There are approximately 30 upcalls at present
@@ -346,8 +391,12 @@
   Before delving into the specific calls we need to discuss a variety of
   data structures shared by the kernel and Venus.
 
+
+
+
   44..11..  DDaattaa ssttrruuccttuurreess sshhaarreedd bbyy tthhee kkeerrnneell aanndd VVeennuuss
 
+
   The CodaCred structure defines a variety of user and group id's as
   they are set for the calling process. The vuid_t and guid_t are 32 bit
   unsigned integers.  It also defines group member ship in an array.  On
@@ -361,10 +410,13 @@
       vgid_t cr_groups[NGROUPS];        /* Group membership for caller */
   };
 
+
+
   NNOOTTEE It is questionable if we need CodaCreds in Venus. Finally Venus
   doesn't know about groups, although it does create files with the
   default uid/gid.  Perhaps the list of group membership is superfluous.
 
+
   The next item is the fundamental identifier used to identify Coda
   files, the ViceFid.  A fid of a file uniquely defines a file or
   directory in the Coda filesystem within a _c_e_l_l.   (-- A _c_e_l_l is a
@@ -372,12 +424,15 @@
   control machine or SCM. See the Coda Administration manual for a
   detailed description of the role of the SCM.--)
 
+
   typedef struct ViceFid {
       VolumeId Volume;
       VnodeId Vnode;
       Unique_t Unique;
   } ViceFid;
 
+
+
   Each of the constituent fields: VolumeId, VnodeId and Unique_t are
   unsigned 32 bit integers.  We envisage that a further field will need
   to be prefixed to identify the Coda cell; this will probably take the
@@ -388,6 +443,23 @@
   exchange information.  It has room for future extensions such as
   support for device files (currently not present in Coda).
 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
   struct coda_vattr {
           enum coda_vtype va_type;        /* vnode type (for create) */
           u_short         va_mode;        /* files access mode and type */
@@ -410,9 +482,13 @@
           long            va_spare;       /* remain quad aligned */
   };
 
+
+
+
   44..22..  TThhee ppiiooccttll iinntteerrffaaccee
 
-  Coda specific requests can be made by application through a pioctl
+
+  Coda specific requests can be made by application through the pioctl
   interface. The pioctl is implemented as an ordinary ioctl on a
   ficticious file /coda/.CONTROL.  The piocl call opens this file, gets
   a file handle and makes the ioctl call. Finally it closes the file.
@@ -429,14 +505,19 @@
           int follow;
       } data;
 
+
+
   where
 
+
   struct ViceIoctl {
           caddr_t in, out;        /* Data to be transferred in, or out */
           short in_size;          /* Size of input buffer <= 2K */
           short out_size;         /* Maximum size of output buffer, <= 2K */
   };
 
+
+
   The path must be a Coda file, otherwise the ioctl upcall will not be
   made.
 
@@ -449,6 +530,7 @@
 
   44..33..  rroooott
 
+
   AArrgguummeennttss
 
      iinn empty
@@ -459,6 +541,8 @@
                     ViceFid VFid;
                 } cfs_root;
 
+
+
   DDeessccrriippttiioonn This call is made to Venus during the initialization of
   the Coda filesystem. If the result is zero, the cfs_root structure
   contains the ViceFid of the root of the Coda filesystem. If a non-zero
@@ -470,6 +554,7 @@
 
   44..44..  llooookkuupp
 
+
   SSuummmmaarryy Find the ViceFid and type of an object in a directory if it
   exists.
 
@@ -482,6 +567,8 @@
                     char        *name;          /* Place holder for data. */
                 } cfs_lookup;
 
+
+
      oouutt
 
                 struct cfs_lookup_out {
@@ -489,6 +576,8 @@
                     int vtype;
                 } cfs_lookup;
 
+
+
   DDeessccrriippttiioonn This call is made to determine the ViceFid and filetype of
   a directory entry.  The directory entry requested carries name name
   and Venus will search the directory identified by cfs_lookup_in.VFid.
@@ -512,6 +601,7 @@
 
   44..55..  ggeettaattttrr
 
+
   SSuummmmaarryy Get the attributes of a file.
 
   AArrgguummeennttss
@@ -523,12 +613,16 @@
                     struct coda_vattr attr; /* XXXXX */
                 } cfs_getattr;
 
+
+
      oouutt
 
                 struct cfs_getattr_out {
                     struct coda_vattr attr;
                 } cfs_getattr;
 
+
+
   DDeessccrriippttiioonn This call returns the attributes of the file identified by
   fid.
 
@@ -549,6 +643,7 @@
 
   44..66..  sseettaattttrr
 
+
   SSuummmmaarryy Set the attributes of a file.
 
   AArrgguummeennttss
@@ -560,6 +655,9 @@
                     struct coda_vattr attr;
                 } cfs_setattr;
 
+
+
+
      oouutt
         empty
 
@@ -577,6 +675,7 @@
 
   44..77..  aacccceessss
 
+
   SSuummmmaarryy
 
   AArrgguummeennttss
@@ -588,11 +687,13 @@
                     int flags;
                 } cfs_access;
 
+
+
      oouutt
         empty
 
   DDeessccrriippttiioonn Verify if access to the object identified by VFid for
-  operetions described by flags is permitted.  The result indicates if
+  operations described by flags is permitted.  The result indicates if
   access will be granted.  It is important to remember that Coda uses
   ACL's to enforce protection and that ultimately the servers, not the
   clients enforce the security of the system.  The result of this call
@@ -605,6 +706,7 @@
 
   44..88..  ccrreeaattee
 
+
   SSuummmmaarryy Invoked to create a file
 
   AArrgguummeennttss
@@ -619,6 +721,9 @@
                     char        *name;          /* Place holder for data. */
                 } cfs_create;
 
+
+
+
      oouutt
 
                 struct cfs_create_out {
@@ -626,6 +731,8 @@
                     struct coda_vattr attr;
                 } cfs_create;
 
+
+
   DDeessccrriippttiioonn  This upcall is invoked to request creation of a file.
   The file will be created in the directory identified by VFid, its name
   will be name, and the mode will be mode.  If excl is set an error will
@@ -637,6 +744,7 @@
   instantiate a vnode, inode or filehandle at kernel level for the new
   object.
 
+
   EErrrroorrss A variety of errors can occur. Permissions may be insufficient.
   If the object exists and is not a file the error EISDIR is returned
   under Unix.
@@ -657,6 +765,7 @@
 
   44..99..  mmkkddiirr
 
+
   SSuummmmaarryy Create a new directory.
 
   AArrgguummeennttss
@@ -669,6 +778,8 @@
                     char        *name;          /* Place holder for data. */
                 } cfs_mkdir;
 
+
+
      oouutt
 
                 struct cfs_mkdir_out {
@@ -676,6 +787,9 @@
                     struct coda_vattr attr;
                 } cfs_mkdir;
 
+
+
+
   DDeessccrriippttiioonn This call is similar to create but creates a directory.
   Only the mode field in the input parameters is used for creation.
   Upon successful creation, the attr returned contains the attributes of
@@ -693,6 +807,7 @@
 
   44..1100..  lliinnkk
 
+
   SSuummmmaarryy Create a link to an existing file.
 
   AArrgguummeennttss
@@ -705,6 +820,8 @@
                     char        *tname;         /* Place holder for data. */
                 } cfs_link;
 
+
+
      oouutt
         empty
 
@@ -716,7 +833,8 @@
 
   EErrrroorrss The usual errors can occur.0wpage
 
-  44..1111..  ssyynnlliinnkk
+  44..1111..  ssyymmlliinnkk
+
 
   SSuummmmaarryy create a symbolic link
 
@@ -731,12 +849,14 @@
                     char        *tname;
                 } cfs_symlink;
 
+
+
      oouutt
         none
 
   DDeessccrriippttiioonn Create a symbolic link. The link is to be placed in the
   directory identified by VFid and named tname.  It should point to the
-  pathname srcname.  The attributes of the newly creaeted object are to
+  pathname srcname.  The attributes of the newly created object are to
   be set to attr.
 
   EErrrroorrss
@@ -748,6 +868,7 @@
 
   44..1122..  rreemmoovvee
 
+
   SSuummmmaarryy Remove a file
 
   AArrgguummeennttss
@@ -759,6 +880,8 @@
                     char        *name;          /* Place holder for data. */
                 } cfs_remove;
 
+
+
      oouutt
         none
 
@@ -774,6 +897,7 @@
 
   44..1133..  rrmmddiirr
 
+
   SSuummmmaarryy Remove a directory
 
   AArrgguummeennttss
@@ -785,6 +909,8 @@
                     char        *name;          /* Place holder for data. */
                 } cfs_rmdir;
 
+
+
      oouutt
         none
 
@@ -800,6 +926,7 @@
 
   44..1144..  rreeaaddlliinnkk
 
+
   SSuummmmaarryy Read the value of a symbolic link.
 
   AArrgguummeennttss
@@ -810,6 +937,8 @@
                     ViceFid VFid;
                 } cfs_readlink;
 
+
+
      oouutt
 
                 struct cfs_readlink_out {
@@ -817,6 +946,8 @@
                     caddr_t     data;           /* Place holder for data. */
                 } cfs_readlink;
 
+
+
   DDeessccrriippttiioonn This routine reads the contents of symbolic link
   identified by VFid into the buffer data.  The buffer data must be able
   to hold any name up to CFS_MAXNAMLEN (PATH or NAM??).
@@ -827,6 +958,7 @@
 
   44..1155..  ooppeenn
 
+
   SSuummmmaarryy Open a file.
 
   AArrgguummeennttss
@@ -838,6 +970,8 @@
                     int flags;
                 } cfs_open;
 
+
+
      oouutt
 
                 struct cfs_open_out {
@@ -845,6 +979,8 @@
                     ino_t       inode;
                 } cfs_open;
 
+
+
   DDeessccrriippttiioonn  This request asks Venus to place the file identified by
   VFid in its cache and to note that the calling process wishes to open
   it with flags as in open(2).  The return value to the kernel differs
@@ -852,7 +988,6 @@
   informed of the device and inode number of the container file in the
   fields dev and inode.  For Windows the path of the container file is
   returned to the kernel.
-
   EErrrroorrss
 
   NNOOTTEE Currently the cfs_open_out structure is not properly adapted to
@@ -864,6 +999,7 @@
 
   44..1166..  cclloossee
 
+
   SSuummmmaarryy Close a file, update it on the servers.
 
   AArrgguummeennttss
@@ -875,6 +1011,8 @@
                     int flags;
                 } cfs_close;
 
+
+
      oouutt
         none
 
@@ -896,6 +1034,7 @@
 
   44..1177..  iiooccttll
 
+
   SSuummmmaarryy Do an ioctl on a file. This includes the piocl interface.
 
   AArrgguummeennttss
@@ -910,13 +1049,18 @@
                     char *data;                 /* Place holder for data. */
                 } cfs_ioctl;
 
+
+
      oouutt
 
+
                 struct cfs_ioctl_out {
                     int len;
                     caddr_t     data;           /* Place holder for data. */
                 } cfs_ioctl;
 
+
+
   DDeessccrriippttiioonn Do an ioctl operation on a file.  The command, len and
   data arguments are filled as usual.  flags is not used by Venus.
 
@@ -925,10 +1069,12 @@
   NNOOTTEE Another bogus parameter.  flags is not used.  What is the
   business about PREFETCHING in the Venus' code?
 
+
   0wpage
 
   44..1188..  rreennaammee
 
+
   SSuummmmaarryy Rename a fid.
 
   AArrgguummeennttss
@@ -942,6 +1088,8 @@
                     char        *destname;
                 } cfs_rename;
 
+
+
      oouutt
         none
 
@@ -956,6 +1104,7 @@
 
   44..1199..  rreeaaddddiirr
 
+
   SSuummmmaarryy Read directory entries.
 
   AArrgguummeennttss
@@ -968,6 +1117,9 @@
                     int offset;
                 } cfs_readdir;
 
+
+
+
      oouutt
 
                 struct cfs_readdir_out {
@@ -975,6 +1127,8 @@
                     caddr_t     data;           /* Place holder for data. */
                 } cfs_readdir;
 
+
+
   DDeessccrriippttiioonn Read directory entries from VFid starting at offset and
   read at most count bytes.  Returns the data into data and indicates
   the size returned size.
@@ -989,15 +1143,18 @@
 
   44..2200..  vvggeett
 
+
   SSuummmmaarryy instructs Venus to do an FSDB->Get.
 
   AArrgguummeennttss
 
      iinn
 
-                struct cfs_fsync_in {
+                struct cfs_vget_in {
                     ViceFid VFid;
-                } cfs_fsync;
+                } cfs_vget;
+
+
 
      oouutt
 
@@ -1006,6 +1163,8 @@
                     int vtype;
                 } cfs_vget;
 
+
+
   DDeessccrriippttiioonn This upcall asks Venus to do a get operation on an fsobj
   labelled by VFid.
 
@@ -1020,6 +1179,7 @@
 
   44..2211..  ffssyynncc
 
+
   SSuummmmaarryy Tell Venus to update the RVM attributes of a file.
 
   AArrgguummeennttss
@@ -1030,6 +1190,8 @@
                     ViceFid VFid;
                 } cfs_fsync;
 
+
+
      oouutt
         none
 
@@ -1045,6 +1207,7 @@
 
   44..2222..  iinnaaccttiivvee
 
+
   SSuummmmaarryy Tell Venus a vnode is no longer in use.
 
   AArrgguummeennttss
@@ -1055,6 +1218,8 @@
                     ViceFid VFid;
                 } cfs_inactive;
 
+
+
      oouutt
         none
 
@@ -1068,6 +1233,7 @@
 
   44..2233..  rrddwwrr
 
+
   SSuummmmaarryy Read or write from a file
 
   AArrgguummeennttss
@@ -1083,6 +1249,9 @@
                     caddr_t     data;           /* Place holder for data. */
                 } cfs_rdwr;
 
+
+
+
      oouutt
 
                 struct cfs_rdwr_out {
@@ -1091,6 +1260,8 @@
                     caddr_t     data;   /* Place holder for data. */
                 } cfs_rdwr;
 
+
+
   DDeessccrriippttiioonn This upcall asks Venus to read or write from a file.
 
   EErrrroorrss
@@ -1099,10 +1270,12 @@
   read/write operations never reach Venus.  I have been told the
   operation does not work.  It is not currently used.
 
+
   0wpage
 
   44..2244..  ooddyymmoouunntt
 
+
   SSuummmmaarryy Allows mounting multiple Coda "filesystems" on one Unix mount
   point.
 
@@ -1114,12 +1287,16 @@
                     char        *name;          /* Place holder for data. */
                 } ody_mount;
 
+
+
      oouutt
 
                 struct ody_mount_out {
                     ViceFid VFid;
                 } ody_mount;
 
+
+
   DDeessccrriippttiioonn  Asks Venus to return the rootfid of a Coda system named
   name.  The fid is returned in VFid.
 
@@ -1133,12 +1310,14 @@
 
   44..2255..  ooddyy__llooookkuupp
 
+
   SSuummmmaarryy Looks up something.
 
   AArrgguummeennttss
 
      iinn irrelevant
 
+
      oouutt
         irrelevant
 
@@ -1152,6 +1331,7 @@
 
   44..2266..  ooddyy__eexxppaanndd
 
+
   SSuummmmaarryy expands something in a dynamic set.
 
   AArrgguummeennttss
@@ -1171,6 +1351,7 @@
 
   44..2277..  pprreeffeettcchh
 
+
   SSuummmmaarryy Prefetch a dynamic set.
 
   AArrgguummeennttss
@@ -1188,10 +1369,12 @@
 
   NNOOTTEE Gut it. It isn't working and isn't used by Coda.
 
+
   0wpage
 
   44..2288..  ssiiggnnaall
 
+
   SSuummmmaarryy Send Venus a signal about an upcall.
 
   AArrgguummeennttss
@@ -1219,6 +1402,7 @@
 
   55..  TThhee mmiinniiccaacchhee aanndd ddoowwnnccaallllss
 
+
   The Coda FS Driver can cache results of lookup and access upcalls, to
   limit the frequency of upcalls.  Upcalls carry a price since a process
   context switch needs to take place.  The counterpart of caching the
@@ -1227,8 +1411,8 @@
 
   The kernel code generally has to maintain a structure which links the
   internal file handles (called vnodes in BSD, inodes in Linux and
-  FileHandles in Windows) with the ViceFid's which Venus maintains.
-  Ther reason is that frequent translations back and forth are needed in
+  FileHandles in Windows) with the ViceFid's which Venus maintains.  The
+  reason is that frequent translations back and forth are needed in
   order to make upcalls and use the results of upcalls.  Such linking
   objects are called ccnnooddeess.
 
@@ -1246,7 +1430,7 @@
   The lookup call in the Coda FS Driver may request the cnode of the
   desired object from the cache, by passing it's name, directory and the
   CodaCred's of the caller.  The cache will return the cnode or indicate
-  and it cannot be found.  The Coda FS Driver must be careful to
+  that it cannot be found.  The Coda FS Driver must be careful to
   invalidate cache entries when it modifies or removes objects.
 
   When Venus obtains information that indicates that cache entries are
@@ -1255,12 +1439,17 @@
   the kind described below.  The Coda FS Driver does not return an error
   unless the downcall data could not be read into kernel memory.
 
+
   55..11..  IINNVVAALLIIDDAATTEE
 
+
   No information is available on this call.
 
+
   55..22..  FFLLUUSSHH
 
+
+
   AArrgguummeennttss None
 
   SSuummmmaarryy Flush the name cache entirely.
@@ -1270,25 +1459,33 @@
   systems allow the kernel name cache to be switched off dynamically.
   When this is done, this downcall is made.
 
+
   55..33..  PPUURRGGEEUUSSEERR
 
+
   AArrgguummeennttss
 
           struct cfs_purgeuser_out {/* CFS_PURGEUSER is a venus->kernel call */
               struct CodaCred cred;
           } cfs_purgeuser;
 
+
+
   DDeessccrriippttiioonn Remove all entries in the cache carrying the Cred.  This
   call is issued when tokes for a user expire or are flushed.
 
+
   55..44..  ZZAAPPFFIILLEE
 
+
   AArrgguummeennttss
 
           struct cfs_zapfile_out {  /* CFS_ZAPFILE is a venus->kernel call */
               ViceFid CodaFid;
           } cfs_zapfile;
 
+
+
   DDeessccrriippttiioonn Remove all entries which have the (dir vnode, name) pair.
   This is issued as a result of an invalidation of cached attributes of
   a vnode.
@@ -1297,20 +1494,28 @@
   zapfile routine takes different arguments. Linux does not implement
   the invalidation of attributes correctly.
 
+
+
   55..55..  ZZAAPPDDIIRR
 
+
   AArrgguummeennttss
 
           struct cfs_zapdir_out {   /* CFS_ZAPDIR is a venus->kernel call */
               ViceFid CodaFid;
           } cfs_zapdir;
 
+
+
   DDeessccrriippttiioonn Remove all entries in the cache lying in a directory
   CodaFid, and all children of this directory. This call is issed when
-  Venus receives a callback on the this directory.
+  Venus receives a callback on the directory.
+
 
   55..66..  ZZAAPPVVNNOODDEE
 
+
+
   AArrgguummeennttss
 
           struct cfs_zapvnode_out { /* CFS_ZAPVNODE is a venus->kernel call */
@@ -1318,11 +1523,15 @@
               ViceFid VFid;
           } cfs_zapvnode;
 
+
+
   DDeessccrriippttiioonn Remove all entries in the cache carrying the cred and VFid
   as in the arguments. This downcall is probably never issued.
 
+
   55..77..  PPUURRGGEEFFIIDD
 
+
   SSuummmmaarryy
 
   AArrgguummeennttss
@@ -1331,12 +1540,17 @@
               ViceFid CodaFid;
           } cfs_purgefid;
 
+
+
   DDeessccrriippttiioonn Flush the attribute for the file. If it is a dir (odd
   vnode), purge its children from the namecache remove the file from the
   namecache.
 
+
+
   55..88..  RREEPPLLAACCEE
 
+
   SSuummmmaarryy Replace the Fid's for a collection of names.
 
   AArrgguummeennttss
@@ -1346,6 +1560,8 @@
               ViceFid OldFid;
           } cfs_replace;
 
+
+
   DDeessccrriippttiioonn This routine replaces a ViceFid in the name cache with
   another.  It is added to allow Venus during reintegration to replace
   locally allocated temp fids while disconnected with global fids even
@@ -1355,11 +1571,13 @@
 
   66..  IInniittiiaalliizzaattiioonn aanndd cclleeaannuupp
 
+
   This section gives brief hints as to desirable features for the Coda
   FS Driver at startup and upon shutdown or Venus failures.  Before
   entering the discussion it is useful to repeat that the Coda FS Driver
   maintains the following data:
 
+
   1. message queues
 
   2. cnodes
@@ -1383,8 +1601,10 @@
      Currently the _p_i_o_c_t_l passes through the VFS for Coda so we can
      treat these similarly.
 
+
   66..11..  RReeqquuiirreemmeennttss
 
+
   The following requirements should be accomodated:
 
   1. The message queueus should have open and close routines.  On Unix
@@ -1399,6 +1619,7 @@
 
   +o  Close will free all memory allocated by the message queues.
 
+
   2. At open the namecache shall be initialized to empty state.
 
   3. Before the message queues are open, all VFS operations will fail.
@@ -1424,4 +1645,6 @@
   NNOOTTEE  NetBSD in particular but also Linux have not implemented the
   above requirements fully.  For smooth operation this needs to be
   corrected.
+
+
 

FUNET's LINUX-ADM group, linux-adm@nic.funet.fi
TCL-scripts by Sam Shen, slshen@lbl.gov