Jeffrey Hutzelman wrote:
Of course it might and for each change the client would receive a callback stating what range was updated.Actually, it may turn out that the improvement you get is the other way around. The file may change several times while someone else continues to hold the lock.
The Windows cache manager would make use of this data today by invalidating just the affected buffers and then increasing the range of data versions for which buffers are valid by one. This would permit the cache manager to minimize the number of reads that must be performed from the file server in the future.
This is a natural incremental modification to what the Windows cache manager already implements.
Jeffrey Altman P.S.The Window CM maintains in the cm_scache_t object both the current data version and a minimum valid buffer data version. The minimum valid buffer data version is not incremented as a result of a Store Data, Set File Length, Directory modification, etc. that results in a data version delta of one. In that scenario the existing buffer versions held by the cache manager are known to be valid and only newly read buffers are given the current data version. This eliminates the need to re-read buffers from the file as well as eliminates the need to update the data version associated with each buffer as part of the Merge Status operation.
If the delta is not one, the cache manager knows that there was a change to the object that was not of local origination and the minimum valid buffer data version is set to the new data version value.
In both cases, the Merge Status operation can be performed in constant time and without regard to the length of the file or the number of cached buffers.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
