Venus and Vice will access directories through the directory handle api. A directory handle facilitates: - locking of directories - managing rvm and non rvm copies of the data
Directory handles are opaque but have a simple internal structure:
struct DirHandle { lock dh_lock; PDirHeader dh_vmdata; PDirHeader dh_rvmdata; int dh_refcount; };
Lock the direcotry for writing
release a write lock
release a read lock
initializes the lock in a directory handle.
Instantiate a new directory handle in in VM or RVM and attach directory header pointers to the fields. This routine is probably not useful to Venus and Vice since DirHandle structures are embedded in other structures.
return the length of the directory in bytes. This will always be a multiple of the DIR_PAGESIZE (2048 bytes)
Lookup an entry in the directory dh and fill in the fid. This call returns 0 upon success.
Remove entry from dh. Return 0 upon success.
Free the data pointed toby (r)vm data field in the handle.
Allocate (recoverable) memory of size size in the DirHeader pointers in the dh.
Return a pointer tothe dirheader in the dirhandle.
Print the complete structure of the directory
Create a new directory. This call will allocate memory in (r)vm based on the return vlaue of dir_rvm()
This call williterate through the directory entries and apply hookproc to each, with parameter the dir entry in question and the hook pointer. It will quit when all entries have been processed or when hookproc returns a nonzero value.
The final return value is returned by DH_EnumerateDir.
The DIR api handles the actions on the directory data blobs. These routines are probably only used by the DH api and not elsewhere in the code. This important since it will make switching to a new directory type easy.
The internalhandling of the directory buffers is important. New entries can be created and the routine dir_FindBlobs will locate a sufficient number of blobs. If none are available anymore in the directory the routine dir_AddPage is called. AddPage reallocates a directory buffer which is one pagesize (2048 bytes) larger and then copies the old data into the new one (dir_Extend). Of course this requires a rvm_set_range call when the data is in RVM. After this is done, it adjusts the bitmaps and free counts.
Tells Venus/Vice if directory data is manipulated in RVM or VM. Venus will directly doits transactions on the RVM data (following the pointer in DH). The server manipulates a VM handle and commits the entire blob at commit time.
Hash value of the name -- could probably be static.
This routine is probably going to be obsolete.
Make a new directory with "." and ".." entries as indicated by me and papa.
The normal important lookup of a name in a directory.
Enumerate untilhookproc returns non-null. Return final return value of hookproc.
Create a directory entry
Length of the directory
delete an entry
print out a hash chain in a directory
Convert a directory to Venus BSD format for parsing by the kernel.
sect2 > static int dir_NameBlobs (char *name)
How many blobs are needed for this name?
Find a bunch of contiguous entries; at least nblobs in a row.
Add a page to a directory. This routine has two components. It calls dir_Extend and when the new buffer is made available adjusts the bitmaps, freecounts, etc.
This is the routine which allocates a new buffer (exactly one page larger than the former size of the directory) and frees the previous buffer. Of ocurse it uses a transaction in RVM if this is where data is held.
Return the PageHeader for the page
page
in the
directory.
This is called delete. It makes a group of blobs available again for re-allocation to new entries.
There are a variety of fid supporting routines needed in the dir package. The primary
1. ViceFids in use by Venus and Vice are structures containing more information (such as cell and volume information) than fids stored in Coda directories which only contain a vnode and uniquifier.
2. Directories are stored on disk in network order. This means that conversion to host order is appropriate and needs a few supporting routines.
Copy a ViceFid's vnode and unique fields into a directory fid.
Copy a directory Fid's vnode and unique field into a ViceFid.
Load integers into a fid
Take vnode and unique out of a directory network fid.
Print a fid
Give a printed version of the fid in a string (statically allocated). Allows for ....
Convert fid to network order
Convert fid to host order
Is a network fid equal to a fid?
Copy the pages in a directory inode to a contiguous area in VM for which memory is malloced. The directory header (i.e. the first page of this data in VM) is returned.
Store the pages found in a VM area in RVM. This involves setting ranges and potentially allocating new pages in persistent storage for the object.
Increase the reference count to the directory (after a clone for example) in persistent storage.
Decrease the RVM refcount on the directory. Remove the directory when this falls to 0.
Returns the reference count on a directory.
Return the number of pages in the directory.
Return a pointer to a page.
Make a copy of a directory inode and the pages. Needed by copy on write.
Set up the DH hashtable.
Decrease the refcount on a hashed directory handle. Remove it when it falls to 0.
Increase the reference count on a cached directory handle or fetch the handle and the data from RVM if not hashed yet.