In addition to backup and readonly clones, you may create up to three additional clones of a volume. To do this, use "vos clone".
-When you "vos remove" a volume, its "backup" clone will also be removed automatically. However, clones created with "vos clone" are **not** removed automatically. Unfortunately, these "dangling clones" will no longer be in the VLDB (see question 3.47).
+When you "vos remove" a volume, its "backup" clone will also be removed automatically. However, clones created with "vos clone" are **not** removed automatically. Unfortunately, these "dangling clones" will no longer be in the VLDB (see question 3.47). They belong to a volume group whose leader (rw volume) no longer exists, which is a somewhat undefined state for AFS. Such volumes should be manually deleted as soon as possible.
### <a name="3.50 What is a Shadow?"></a> 3.50 What is a Shadow?
A shadow of a volume is a duplicate of that volume which resides on a different partition. Shadow volumes do not share storage with their original volumes (unlike clones). A readonly volume on a **different** partition than its readwrite volume could be considered one particular example of a shadow volume; however, in practice the term "shadow volume" is used to refer to volumes created with "vos shadow" and not to refer to readonly volumes.
-A shadow of any readwrite volume may be created using the "vos shadow" command. This will create a new volume which is a shadow of the original volume, and will copy the contents of the old volume to the new volume. This will also set a bit in the header of the new shadow volume that identifies it as a shadow volume. Shadow volumes do not appear in the VLDB (see question 3.47)
+A shadow of any readwrite volume may be created using the "vos shadow" command. This will create a new volume which is a shadow of the original volume, and will copy the contents of the old volume to the new volume. This will also set a bit in the header of the new shadow volume that identifies it as a shadow volume. Shadow volumes do not appear in the VLDB (see question 3.47) -- "vos shadow" does not create a VLDB entry and "vos syncvldb" ignores shadow volumes.
You can "refresh" a shadow volume from its original with "vos shadow -incremental". This operation will first check to make sure that the target of the operation is a shadow volume, to prevent the administrator from accidentally corrupting a non-shadow volume. However, if you shadow from a readwrite volume to some shadow of **another** volume, the shadow will be corrupted and will have to be deleted. Vos shadow will only copy data which has changed, so it is very efficient.
-You can remove the shadow bit from a volume's header with "vos shadow -live". This will remove the shadow bit and create a VLDB entry for the volume.
+You can remove the shadow bit from a volume's header with "vos shadow -live". This will remove the shadow bit and create a VLDB entry for the volume, deleting any previous entry for the rw volume. However, the rw volume itself will not be deleted; it will simply exist without a VLDB entry.
+
+Attempting to create shadows of two different rw volumes on the same partition with the same name is prohibited by the volserver. Technically it is possible to create two shadow volumes with the same name on different partitions; however, this is not advisable.
- **find | grep** is very helpful. For example, to find all the RX packages (ie, so that you can start to identify the various namespaces of components), you can do:
-` find . -name \*.xg -exec grep -H "^package" {} \; | grep -v 'example' | grep -v 'bulktest' | sed -e 's|^./src/||' | sed -e 's/package/ /' | awk '{printf "%10s %s\n", $2, $1}' `
-
-which results in: ` VOTE_ ubik/ubik_int.xg: DISK_ ubik/ubik_int.xg: SAMPLE_ ubik/utst_int.xg: VL_ vlserver/vldbint.xg: UPDATE_ update/update.xg: TEST_ rxgk/test.xg: RXGK_ rxgk/rxgk_proto.xg: RXAFSCB_ fsint/afscbint.xg: RXAFS_ fsint/afsint.xg: RXSTATS_ rxstat/rxstat.xg: PR_ ptserver/ptint.xg: BOZO_ bozo/bosint.xg: BUMON_ bubasics/backmon.xg: TC_ bubasics/butc.xg: BC_ bubasics/bumon.xg: ADK_ dauth/adkint.xg: RMTSYS_ sys/rmtsys.xg: AFSVol volser/volint.xg: `
+ find . -name \*.xg -exec grep -H "^package" {} \; | grep -v 'example' | grep -v 'bulktest' | \
+ sed -e 's|^./src/||' | sed -e 's/package/ /' | awk '{printf "%10s %s\n", $2, $1}'
+
+which results in:
+
+ VOTE_ ubik/ubik_int.xg:
+ DISK_ ubik/ubik_int.xg:
+ SAMPLE_ ubik/utst_int.xg:
+ VL_ vlserver/vldbint.xg:
+ UPDATE_ update/update.xg:
+ TEST_ rxgk/test.xg:
+ RXGK_ rxgk/rxgk_proto.xg:
+ RXAFSCB_ fsint/afscbint.xg:
+ RXAFS_ fsint/afsint.xg:
+ RXSTATS_ rxstat/rxstat.xg:
+ PR_ ptserver/ptint.xg:
+ BOZO_ bozo/bosint.xg:
+ BUMON_ bubasics/backmon.xg:
+ TC_ bubasics/butc.xg:
+ BC_ bubasics/bumon.xg:
+ ADK_ dauth/adkint.xg:
+ RMTSYS_ sys/rmtsys.xg:
+ AFSVol volser/volint.xg:
In other words, if something starts with BOZO\_, you know that it is generated by rxgen, and the interface is defined in `bozo/bosint.xg`.
In addition to the package name, also note that only rxstat uses an M prefix; all others use S.
-- cscope: what it is, how to set up, how to use, example
+- cscope: a source code browser, linked to your editor. Setup is simple: cd to your source tree and run:
+
+ find . -name \*.[ch] > namelist
+ cscope -R -b
+
+Then run
+
+ cscope -d
+
+to start. The interface is simple. I tend to use it for finding things, but not necessarily for editing. When I'm studying the source, trying to understand how components link together, or bug-hunting, I tend to live inside `cscope`.
+
- doxygen: what it is, how to set up, how to use, how to make even more useful (ie, src code changes)
+
- gdb: examples of using (primarily b, bt)
git://git.openafs.org / openafs-wiki.git / commitdiff