windows-callback-restore-multi-cell-servers-20071226
authorJeffrey Altman <jaltman@secure-endpoints.com>
Wed, 26 Dec 2007 16:18:37 +0000 (16:18 +0000)
committerJeffrey Altman <jaltman@secure-endpoints.com>
Wed, 26 Dec 2007 16:18:37 +0000 (16:18 +0000)
commit56a82598b19e4232b0095c2b5778d4571c8aa9b2
treec9a8732811a16c770e4bcceb8a3daa06c894e272
parentb41b3bb52eaba52bba8fda0c49083322d6959238
windows-callback-restore-multi-cell-servers-20071226

LICENSE MIT

The case of openafs.org and grand.central.org is a hideous abuse of
the AFS cell name space.  There are many negatives associated with
trying to support two different cell names pointing at overlapping
vlserver lists:

(1) The CM can store duplicate entries for all of the data simply because
    the cell name that was used is different

(2) If the CM attempts to optimize the data storage by aliasing or otherwise
    combining the cell names as part of one cm_cell_t object, then future
    attempts to separate the two cell names will require the destruction
    of the cache.

(3) If the CM does not associate a callback revoke with a particular cell,
    then the status data associated with any entry that matches the revoked
    AFSFid will be discarded.  For volume callbacks this can have a serious
    impact because volume IDs are not unique across cells and discarding
    status data for readonly volumes that are in use can result in a
    significant number of FetchStatus requests being sent to the associated
    file server.

There are other issues as well involving authentication.

The case of openafs.org advertising the vlserver addresses of
grand.central.org should be considered a hack; a hack that the Windows
client will no longer ensure will work.

Additional debugging messages have been added to assist individuals attempting
to debug why callback revokes do not appear to take affect when two cell
names share the same vlserver data.
src/WINNT/afsd/cm_callback.c
src/WINNT/afsd/cm_cell.c