[9277] in Athena Bugs
fs flushvol: continued investigation
daemon@ATHENA.MIT.EDU (Richard Basch)
Tue May 5 17:23:03 1992
Date: Tue, 5 May 92 17:22:27 -0400
To: bugs@MIT.EDU, bug-afs@MIT.EDU, trb@MIT.EDU, athena-ws@MIT.EDU
From: "Richard Basch" <basch@MIT.EDU>
Ok, after conversing with Mike Stolarchuk (UMich), I have a better
understanding of the AFS cache mechanism.
The problems that I described with the LRU cache are real, and the
improper use of the IFEverUsed flag contributes to the ineffectiveness
of the "fs flushvol" feature. However, my patch which works around both
of these problems will only address a small percentage of the volume.
The way the cache works is that it allocates about 100 dcache structures
and 300 vcache structures (UMich suggests raising these to 300/500 and
instantly get about 10-15% improvement in performance). These work like
a TLB (Translation Lookahead Buffer), and will be replaced with the
attributes of the various disk cache files as required. Thus, the "fs
flushvol" will have to be modified to use the information stored in the
CacheItems file; that contains the complete information. From what we
can formulate, this inefficient TLB was implemented to accomodate the
days of 2MB RTs.
As far as I can tell, "fs flushvol" may have to adversely affect the
dcache list (in any case, this is not going to be a trivial change, or
at least one that I will be comfortable introducing at this late date).
Question: Is this a show-stopper? If so, I will address it, but I'd
rather not be rushed into implementing this change. I have not learned
enough about the cache internals to feel comfortable making changes
beyond what I have already done; it is no longer an obvious fix to a
minor coding error, but an algorithm change...
-Richard
