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> Venus Data Structures: File Cache</TITLE>
 <LINK HREF="venus-ds-3.html" REL=next>
 <LINK HREF="venus-ds-1.html" REL=previous>
 <LINK HREF="venus-ds.html#toc2" REL=contents>
</HEAD>
<BODY>
<A HREF="venus-ds-3.html">Next</A>
<A HREF="venus-ds-1.html">Previous</A>
<A HREF="venus-ds.html#toc2">Contents</A>
<HR>
<H2><A NAME="s2">2. File Cache</A></H2>

<P>
<H2><A NAME="ss2.1">2.1 FSDB -- the file system database  (persisent)</A>
</H2>

<P>This is an umbrella structure.
<UL>
<LI>    fixed number of slots, blocks</LI>
<LI>    Contents:

<UL>
<LI>    links to FSOs:
<UL>
<LI>FSO hash table</LI>
<LI>priority queue (btree)</LI>
<LI>delete queue</LI>
<LI>open for write queue</LI>
</UL>
</LI>
<LI>    statistics</LI>
<LI>    block, file counts</LI>
<LI>    priority weights</LI>
</UL>
</LI>
</UL>
<P>
<H2><A NAME="ss2.2">2.2 FSOBJ -- a slot in the cache (persisent, some transient fields)</A>
</H2>

<P>The fso class contains most of the information about a file system
object. It has pointers to the volume information, part of which is
copied to avoid lookups. There are pointers to the data, which can be
a symlink, file or directory object.  Data structures of type binding
are used to store hoard and cml information.
<P>Fso objects keep track of readers and writers of the object.
<UL>
<LI>    fid</LI>
<LI>    component name</LI>
<LI>    state (normal, runt, dying)</LI>
<LI>    status block (Venus stat, a condensed version of ViceStatus, see vcrcommon) 
vnode type in here, and size, mtime, etc.</LI>
<LI>    access control information</LI>
<LI>    flags (class FsoFlags)
<UL>
<LI>fake, fetching, replaceable, etc.</LI>
<LI>    for volume types (copied) e.g. backup, replicated, etc.</LI>
</UL>
</LI>
<LI>    mount state (normal, mount point, mount root)
links to root, mount point in latter cases</LI>
<LI>    data
<UL>
<LI>    symlinks stored directly in RVM</LI>
<LI>    files stored as container files (CacheFile)</LI>
<LI>    directories stored in RVM
written to container files upon open</LI>
</UL>
</LI>
<LI>    counts (readers, writers, openers, etc.)</LI>
<LI>    links to 
<UL>
<LI>  hash table (fsdb)</LI>
<LI>    volume</LI>
<LI>    priority queue</LI>
<LI>    delete queue</LI>
<LI>    open-for-write queue</LI>
<LI>    parent fso</LI>
<LI>    list of child fsos</LI>
<LI>    HDB bindings    </LI>
<LI>    MLE bindings</LI>
</UL>
</LI>
<LI>    statistics</LI>
</UL>
<H2><A NAME="ss2.3">2.3 CacheFile -- cache container file </A>
</H2>

<P> 
<P>The fso objects are related one-one to cache files.  Methods exported
by cache files are simple on these are things like validate, move,
copy, remove, truncate, reset.  It appears that historically
cachefiles could be accessed through inode calls.  Currently cache
files and fsobjs are statically linked by embedding.
<UL>
<LI>    statically bound to fsobj</LI>
<LI>    container files used in several ways
<UL>
<LI>    to store a plain file</LI>
<LI>    to store a UNIX format directory as a plain file        
(NB: this format is system independent now!)</LI>
</UL>
</LI>
</UL>
<P>
<P>
<HR>
<A HREF="venus-ds-3.html">Next</A>
<A HREF="venus-ds-1.html">Previous</A>
<A HREF="venus-ds.html#toc2">Contents</A>
</BODY>
</HTML>