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
- Lines: 1143
- Date:
Sun Dec 21 14:45:14 1997
- Orig file:
v2.1.74/linux/Documentation/filesystems/coda.txt
- Orig date:
Wed Dec 10 11:12:42 1997
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