salvager: Do not require MaybeZapVolume fileName
authorAndrew Deason <adeason@sinenomine.net>
Tue, 21 Feb 2012 23:46:41 +0000 (17:46 -0600)
committerDerrick Brashear <shadow@dementix.org>
Fri, 24 Feb 2012 12:25:27 +0000 (04:25 -0800)
commit839638870986ebd4cf992f7a2c81a23e37c14228
tree8d733c9527507f64e83763f2c65183318d095db3
parent76f12c2389fd2a8e09b4e869730169401d154ce9
salvager: Do not require MaybeZapVolume fileName

In MaybeZapVolume, currently we do not remove the volume header if the
given isp->volSummary->fileName is not set. This effectively means
that we only actually "zap" volumes for which we have just created the
header, or which are not referenced by any inodes.

For readonly volumes that have errors, we want to delete the volumes
instead of salvaging. Readonly volumes with valid headers will have
fileName as NULL, though (set back in SalvageFileSys1), so
MaybeZapVolume will refuse to remove them. What ends up happening is
that the headers will stay around, but since we do not finish checking
the volume, all of the inodes for the data in the volume will be
dec'd. This results in a volume whose header exists, but none of its
inodes (including special inodes) exist, so the volume will need to be
salvaged again, and during that salvage will be deleted (because there
are no inodes for the volume).

Avoid all this, and just delete volume headers for volumes that lack a
valid fileName. Instead try to avoid deleting headers with
volSummary->deleted set, just so we don't try to delete the same
headers twice.

Related issue reported by ├ůsa Andersson.

Change-Id: I4797d0cabe3851debdc78f4ed9ee619534397970
Reviewed-on: http://gerrit.openafs.org/6784
Reviewed-by: Derrick Brashear <shadow@dementix.org>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
src/vol/vol-salvage.c