vlserver: Return VL_DBBAD on unhash failure 84/13384/4
authorAndrew Deason <adeason@sinenomine.net>
Mon, 12 Nov 2018 21:06:09 +0000 (15:06 -0600)
committerBenjamin Kaduk <kaduk@mit.edu>
Mon, 2 Nov 2020 16:53:43 +0000 (11:53 -0500)
commitfd6add0aca03a5a17f7109c785b6027a76f13cdf
treee9c19cacfe760cea74f565456c9655b7bb4ab67c
parent878d27c845157bb64c32bbd6c3cacce17c681d70
vlserver: Return VL_DBBAD on unhash failure

If we try to delete a vlentry, and the vlentry cannot be found on one
of its hash chains, we cannot unhash the vlentry properly and the
operation fails with VL_NOENT. This results in the following error
messages to the user:

        $ vos delentry 123456
        Could not delete entry for volume 123456
        You must specify a RW volume name or ID (the entire VLDB entry will be deleted)
        VLDB: no such entry
        Deleted 0 VLDB entries

This is confusing, because VL_NOENT can also occur if the user
specifies a volume that does actually not exist. This situation is
indicative of database corruption, usually because of a ubik
transaction that was only half-applied, or because of other ubik bugs
in the past.

The situation can only really be fixed by repairing the database, so
return VL_DBBAD in this case instead, to more clearly indicate that
something is wrong with the database, and not a problem with the
arguments the caller provided.

Change-Id: I6fc275c3ad05c108778f36687227b0a927cca5da
Reviewed-on: https://gerrit.openafs.org/13384
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
src/vlserver/vlutils.c