openafs/doc
Andrew Deason 60e8dcb4e6 DAFS: Maintain viced volume group hierarchy cache
When salvaging a volume (with DAFS or not), it is required to read the
volume headers of all volumes on the partition, so we know what volumes
are in the same volume group as the salvaged volume. Currently with
DAFS, this requirement can make demand-salvages very slow, since each
demand-salvage must read each volume header on the partition.

So, instead of having each demand-salvage read the volume headers
itself, have a demand-salvage request the required volume group
hierarchy information from the fileserver. The fileserver will scan the
partition's volume headers, and will keep the hierarchy cached in
memory. Any modifications to this hierarchy from volume
creation/deletion will update this volume group cache (VGC) via FSSYNC
commands.

This results in a dramatic salvaging speedup when many demand-salvages
are requested, and eliminates the cases where DAFS salvaging can be
significantly slower than non-DAFS salvaging.

FIXES 124488

Change-Id: Ie9ae655593ad8a90ca6ad8f63e6b6e799f283988
Reviewed-on: http://gerrit.openafs.org/880
Reviewed-by: Derrick Brashear <shadow@dementia.org>
Tested-by: Derrick Brashear <shadow@dementia.org>
2010-02-17 09:33:18 -08:00
..
arch DAFS: Maintain viced volume group hierarchy cache 2010-02-17 09:33:18 -08:00
examples provide an example CellAlias file. 2002-07-16 18:39:50 +00:00
man-pages Some minor rewording and grammatical tweaks of the CellAlias man page 2010-02-15 04:53:37 -08:00
pdf initial-pdf-with-embedded-cmr-fonts-20010606 2001-06-06 18:58:13 +00:00
protocol doc-doxygen-20090531 2009-05-31 17:52:46 +00:00
txt Windows: 1.5.72 2010-02-10 21:32:17 -08:00
xml Fix typo in AdminGuide 2010-01-14 16:20:58 -08:00
LICENSE man-page-license-change-20071225 2007-12-25 22:22:22 +00:00
README doc-README-20070410 2007-04-10 20:52:30 +00:00

What's in the "doc" subdirectory

** doc/html
original ibm html doc, no longer used

** doc/man-pages
pod sources for man pages (converted from original ibm html source).

** doc/xml
xml sources for manuals (converted from original ibm html source).  there is
some generated pdf/html content as well for the curious.

Note that doc/xml/AdminReference uses doc/xml/AdminReference/pod2refentry to
convert the pod man pages to xml for printing.  pod goes directly to html
just fine.

The reference guide is now built by converting the existing pod documention
to xml.  however, the indexing information was lost during the initial pod
conversion.  Someone we will need to try to get that back.

** doc/pdf
old Transarc (and possibly pre-Transarc) protocol and API documentation for
which we have no other source

** doc/txt
doc/examples
a few other miscellaneous files.


From: Russ Allbery

The Administrative Reference has been converted into separate POD man pages
for each command, since that's basically what it already was (just in HTML).
Considerable work remains to update that POD documentation to reflect the
current behavior of OpenAFS (for example, there's no documentation of
dynroot, no mention of Kerberos v5, many fileserver options are
undocumented, the afsd switch documentation is out of date, and so forth).
I've collected as many of those deficiencies as I know of in
doc/man-pages/README.  Any contributions to correct any of those deficiences
are very welcome.  This is one easy place to start.

The other reference manuals (the Administrator's Guide, the Quick Start
Guide, and the User's Guide) are more manual-like in their structure.  After
some on-list discussion, we picked DocBook as the format to use going
forward and the existing HTML files have been converted to DocBook with a
script.  This means that the markup could use a lot of cleaning up and the
content is even less updated than the man pages.

I did some *very* initial work on the Quick Start Guide, just to get the
makefile working and to try some simple modifications.  Simon Wilkinson is
currently working on making more extensive modifications.  If you want to
work on the Quick Start Guide, please coordinate with him to avoid duplicate
work.

The Administrator's Guide and User's Guide have not yet been touched.  Of
those, the latter is probably in the best shape, in that the user commands
and behavior haven't changed as much.  If you'd like to start working on one
of those, that would also be great.