[PATCH 39/41] afs: Overhaul invalidation handling to better support RO volumes

[Jeffrey E Altman]

On 11/9/2023 10:40 AM, David Howells wrote:
> This allows better handling of RO (and Backup) volumes.  Since these are
> snapshot of a RW volume that are updated atomically simultantanously across
> all servers that host them, they only require a single callback promise for
> the entire volume.

The atomic visibility of a volume cloning operation is limited to 
individual volume locations.
It is untrue that a "vos release" updates all RO volume locations 
simultaneously.  If that were
to occur then there would be the potential for all volume locations to 
be offline simultaneously
causing an outage.  Instead, the traditional "volume release" process 
updates the RO volume
site co-located with the RW volume site and makes that version visible 
to cache managers.
Then 50% of the remaining sites are updated in parallel followed by the 
remaining sites.

Each time a site is updated to the new version the volume location entry 
is updated to flag
the site as VLSF_NEWREPSITE.  However, changes to the volume location 
site flags might
not be known to the cache manager.   Prior to completion of the "volume 
release" process
it is possible for a cache manager to failover from a newer snapshot to 
an older one.

> The currently upstream code assumes that RO volumes
> operate in the same manner as RW volumes, and that each file has its own
> individual callback - which means that it does a status fetch for *every*
> file in a RO volume, whether or not the volume got "released" (volume
> callback breaks can occur for other reasons too, such as the volumeserver
> taking ownership of a volume from a fileserver).
Knowledge that the volume snapshot has not changed can be used to avoid 
individual
FetchStatus queries when accessing vnodes anonymously.   In that case 
the vnode's
FetchStatus.AnonymousAccess can be trusted to be unchanged. However, for 
authenticated
access the individual FetchStatus or InlineBulkStat queries must still 
be issued because
the FetchStatus.CallerAccess rights are determined not only by the 
access control list
contents but the caller identity's group memberships which might have 
changed.  This
distinction only matters when evaluating authorization decisions.

Jeffrey Altman


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4039 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-afs/attachments/20231109/fac4e146/attachment.p7s>