[OpenAFS-devel] vldb volume id collision safety

[Derrick Brashear]

On Thu, Jul 9, 2009 at 1:56 PM, Andrew Deason<adeason@sinenomine.net> wrote=
:
> Recently I've noticed a few things in the vlserver that I think make
> volume id allocation needlessly unsafe. That is, some operations
> (specifically vos restore/copy being the only user-accessible ways, I
> think) can create volumes with almost any ID. The IDs of the created
> volumes can collide immediately with already-existing ones, or can
> collide later when new volumes are created the normal way (e.g. `vos
> create`), since maxvolid isn't updated.
>
> There's a couple changes I'd like to make to fix that; I'm discussing
> here in case these somehow obstruct normal operations, or I've not
> thought something through in general.
>
> 1. VL_CreateEntry, ReplaceEntry, and UpdateEntry (any others?) should
> bump maxvolid if any of the IDs in the vlentry are greater than
> maxvolid.
>
> 2. VL_CreateEntry, ReplaceEntry, and UpdateEntry should check if _any_
> of the specified volume IDs already exist _anywhere_ in the vldb. =A0For
> example, right now CreateEntry just checks if the supplied RW id already
> exists as an RW id. If the RO or BK ids already exist, or the RW id
> already exists as e.g. an RO, CreateEntry will create the entry anyway.
>
> 2 makes the "does this volume already exist" step in these operations
> take at least 9ish times as long. I assume that that is negligable, or
> at least a small enough delay to justify checking collisions.
>
> Also, 1 is a behavior change; `restore`ing/`copy`ing to a large volume
> id would cause newly-created volume ids to also have large volume ids.

I agreee 100% of 2, 1 I am worried about for precisely the reason you
state, though create (not necessarily update) modifying it worries me
far less.

in general if an id was not specified by the user incrementing
maxvolid would seem to be a good idea, and not in the case of an
override, but things that make that not true also exist. ugh.