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.
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. ThisThe 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).
distinction only matters when evaluating authorization decisions. Jeffrey Altman
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
