Scavenger not deleting orphan entries.

[canthony]

My system has been salvaged and scavenged, but still contains VTOC entries that are orphans (not reachable from ">")

display_vtoce rpv 3

VTOCE "process_dir_dir" (Directory), vtocx 3 on pvtx 1 (rpv)

UID: 505737623552, msl: 205, csl: 0, records: 0

Quota received (S D) (131071 131071)
Time-record product (D) 1.5e-5 page-seconds

updated at 2017-10-12 10:38:10.063360 pst.

Created 2017-10-12 10:38:01.805824 pst
Never dumped
Used 2017-10-12 10:38:01.805824 pst
Modified 2017-10-12 10:38:01.805824 pst

ON:
OFF: deciduous per_process nqsw master_dir nid ncd dnzp damaged

synchronized fm_damaged fm_checksum_valid

Access Class: system_low

vtoc_pathname rpv 3
vtoc_pathname: Entry not found. Cannot completely convert uid path
Pvtx 1 vtocx 3 = >-NOT-LISTED-

[canthony]

Running salvager with -dcf did not fix the issue.

[Eric Swenson]

What the scavenger does

scavenge_vol.info says the scavenger "examines and validates VTOCEs,
deletes per-process and per-bootload VTOCEs from previous bootloads, recovers
lost VTOCEs, recovers lost records, and checks for reused addresses".

It does not check whether a VTOCE is reachable from >. That is a
hierarchy check, which needs pathname resolution. The tool for it is
sweep_pv -gc: "all VTOCEs for which a reverse connection failure is
encountered in resolving their pathnames are" deleted (sweep_pv.info). So
the immediate answer for the reporter is to run sweep_pv rpv -gc.

Why this particular VTOCE was left

The orphan is a directory named process_dir_dir with no flags set. In
particular per_process is OFF, so the scavenger's "previous bootload"
cleanup does not apply to it. This looks like an earlier >process_dir_dir:

• init_branches.pl1 (bound_init_2) renames the previous >process_dir_dir to process_dir_dir.UNIQUE at every boot, so that it can be deleted later, and makes a new one.
• For the new one it sets dp -> dir.per_process_sw = "1"b in the directory header, but nothing appears to set the per-process flag in >pdd's VTOCE. The ticket's display_vtoce output shows it off.
• The VTOCE's name is still process_dir_dir, not process_dir_dir.UNIQUE. So its branch disappeared before the rename, probably in a crash or a salvage of > that lost the entry. Its VTOCE was then left behind, with nothing to free it except sweep_pv -gc.

Possible improvements

1. Mark >pdd per-process in its VTOCE (not only the directory header). The scavenger would then delete stale >pdd VTOCEs automatically, as it does for process directories.
   • Check first how zzBB and the per-process directories get their VTOCE per_process flag, and use the same mechanism.
   • Caution: >pdd itself must survive the current bootload. Whether "from previous bootloads" is decided by a bootload ID in the VTOCE needs checking, so that the current >pdd is not deleted.
2. Find what deletes the renamed process_dir_dir.UNIQUE (the comment says "allows the old one to be deleted"). Confirm that the code which deletes it frees all its VTOCEs.

Recommendation

For the reporter: sweep_pv rpv -gc. For the code: investigate item 1 on a
test system with display_vtoce before and after a reboot, and over a few
boots check whether >pdd VTOCEs accumulate.