Next
Previous
Contents
This is an umbrella structure.
-
fixed number of slots, blocks
-
Contents:
-
links to FSOs:
-
FSO hash table
-
priority queue (btree)
-
delete queue
-
open for write queue
-
statistics
-
block, file counts
-
priority weights
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.
Fso objects keep track of readers and writers of the object.
-
fid
-
component name
-
state (normal, runt, dying)
-
status block (Venus stat, a condensed version of ViceStatus,
see vcrcommon) vnode type in here, and size, mtime, etc.
-
access control information
-
flags (class FsoFlags)
-
fake, fetching, replaceable, etc.
-
for volume types (copied) e.g. backup, replicated, etc.
-
mount state (normal, mount point, mount root) links to root,
mount point in latter cases
-
data
-
symlinks stored directly in RVM
-
files stored as container files (CacheFile)
-
directories stored in RVM written to container files upon
open
-
counts (readers, writers, openers, etc.)
-
links to
-
hash table (fsdb)
-
volume
-
priority queue
-
delete queue
-
open-for-write queue
-
parent fso
-
list of child fsos
-
HDB bindings
-
MLE bindings
-
statistics
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.
-
statically bound to fsobj
-
container files used in several ways
-
to store a plain file
-
to store a UNIX format directory as a plain file (NB: this
format is system independent now!)
Next
Previous
Contents
