• David Howells's avatar
    afs: Detect cell aliases 1 - Cells with root volumes · 8a070a96
    David Howells authored
    Put in the first phase of cell alias detection.  This part handles alias
    detection for cells that have root.cell volumes (which is expected to be
    likely).
    
    When a cell becomes newly active, it is probed for its root.cell volume,
    and if it has one, this volume is compared against other root.cell volumes
    to find out if the list of fileserver UUIDs have any in common - and if
    that's the case, do the address lists of those fileservers have any
    addresses in common.  If they do, the new cell is adjudged to be an alias
    of the old cell and the old cell is used instead.
    
    Comparing is aided by the server list in struct afs_server_list being
    sorted in UUID order and the addresses in the fileserver address lists
    being sorted in address order.
    
    The cell then retains the afs_volume object for the root.cell volume, even
    if it's not mounted for future alias checking.
    
    This necessary because:
    
     (1) Whilst fileservers have UUIDs that are meant to be globally unique, in
         practice they are not because cells get cloned without changing the
         UUIDs - so afs_server records need to be per cell.
    
     (2) Sometimes the DNS is used to make cell aliases - but if we don't know
         they're the same, we may end up with multiple superblocks and multiple
         afs_server records for the same thing, impairing our ability to
         deliver callback notifications of third party changes
    
     (3) The fileserver RPC API doesn't contain the cell name, so it can't tell
         us which cell it's notifying and can't see that a change made to to
         one cell should notify the same client that's also accessed as the
         other cell.
    Reported-by: default avatarJeffrey Altman <jaltman@auristor.com>
    Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
    8a070a96
super.c 17.4 KB