[OpenAFS-devel] Re: vldb volume id collision safety

[Andrew Deason]

On Thu, 9 Jul 2009 14:01:33 -0400
Derrick Brashear <shadow@gmail.com> wrote:

> 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.
>=20
> 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.
>=20
> 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.

What I'm mainly trying to avoid is the process of

vos restore -id maxvolid+1
vos create
problems

This could also be mitigated by point 3 that I forgot to include:

3. GetNewVolumeId should check that the volume IDs it returns are
already used. If they are, just keep bumping maxvolid until they are
not.

--=20
Andrew Deason
adeason@sinenomine.net