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. -- Andrew Deason [email protected] _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
