On Thu, 9 Jul 2009 14:01:33 -0400 Derrick Brashear <[email protected]> wrote:
> On Thu, Jul 9, 2009 at 1:56 PM, Andrew Deason<[email protected]> > 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. For 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. 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. -- Andrew Deason [email protected] _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
