Sophie: coda-doc-5.2.0-4mdk noarch

coda-doc-5.2.0-4mdk.noarch.rpm

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
 <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
 <TITLE> The Coda Dir Package: Directory handling in the server </TITLE>
 <LINK HREF="codadir-3.html" REL=previous>
 <LINK HREF="codadir.html#toc4" REL=contents>
</HEAD>
<BODY>
Next
<A HREF="codadir-3.html">Previous</A>
<A HREF="codadir.html#toc4">Contents</A>
<HR>
<H2><A NAME="s4">4. Directory handling in the server </A></H2>

<P>
<P>
<P>The server has a fairly complicated directory handling system which we describe here. 
<P>
<H2><A NAME="ss4.1">4.1 Persistent storage of directory data </A>
</H2>

<P>
<P>A directory is identified by a vnode, and the vnode's data is stored
in a VnodeDiskObject (cvnode.h).  The <CODE>type</CODE> of the vnode will be
directory and the <CODE>inodeNumber</CODE> will be an RVM pointer to a
<EM>DirInode</EM>.  The dir inode contains an array of page addresses and
a reference count to identify the copy on write references to the
directory.
<P>When the pages are placed in a contiguous buffer, the directory has
the standard structure described in <CODE>codadir.h</CODE>.
<P>
<H2><A NAME="ss4.2">4.2 Directory handles in the server </A>
</H2>

<P>
<P>A key difference between server and client handling of directories is
that there can be more than a single vnode referencing the same
directory inode. In the client only a single fso can point to a dir
header. Generally the vnodes referencing the directory inode will lie
in different volumes, one being a read only clone of another volume.
As a result the directory data is an object which needs to be treated
independently of the vnode.  For this we use a cache of DirHandles.
<P>The interface to the cache is extremely simple: <CODE>DC_HashInit</CODE>
initializes the hash table. <CODE>DC_Get</CODE> takes as argument a pointer to
a DirInode and enters it in the cache if it wasn't in yet, returning
the pointer to the <EM>DirHandle</EM>.  The cache entry has a reference
count which indicates how many VM vnodes are referencing the directory
inode.  The in-core copy of the vnode will have its <EM>DirHandle</EM>
field set to the result returned by DC_Get.  When the directory data
for a Vnode needs to be available, DC_Get is called with argument
<CODE>vnode->disk.inode.</CODE> Previously this was achieved by calling
SetDirHandle.
<P>At this point in time a VM copy of the directory data is available for
manipulation by the fileserver.  The routines DH_Lookup, DH_Delete,
DH_Create etc. are available to search and modify the VM copy of the
directory.  Such changes obtain a write lock on the DirHandle since
the changes will be visible to other threads accessing the directory.
<P>
<P>
<P>
<P>
<P>
<P>
<P>
<P>
<P>
<P>
<P>
<P>
<HR>
Next
<A HREF="codadir-3.html">Previous</A>
<A HREF="codadir.html#toc4">Contents</A>
</BODY>
</HTML>