[9282] in Athena Bugs
Re: fs flushvol: continued investigation
daemon@ATHENA.MIT.EDU (Richard Basch)
Wed May 6 14:08:25 1992
Date: Wed, 6 May 92 14:07:27 -0400
To: akajerry@MIT.EDU
Cc: basch@MIT.EDU, bugs@MIT.EDU, bug-afs@MIT.EDU, trb@MIT.EDU,
In-Reply-To: Jerry Larivee's message of Wed, 6 May 92 01:04:04 -0400,
From: "Richard Basch" <basch@MIT.EDU>
That is the problem; I have no interface to get to the entire on-disk
cache; the memory representation has too little information, and I am
going to have to add quite a bit of new code to break this abstraction
in a place where it did not have this already.
Things are brought into the "TLB-equivalent" memory representation of
the disk cache as they are accessed (like page faults), and I have to
simulate a lot of page-faults; since this is something I am not familiar
with, I am very uncomfortable. So, the same problem applies to flushing
the entire cache as it does to check for a given volume. The check
against whether something exists in a given volume is TRIVIAL. The
problem is cycling through the entire cache. I'd rather not implement
code to do this, as I am sure that it requires various locks and if
those are done wrong and another thread comes along that modifies the
cache doesn't deadlock, we have a likely chance of causing a panic.
-R
