On Tue, Nov 23, 2010 at 6:23 AM, Simon Wilkinson <s...@inf.ed.ac.uk> wrote: > > > On 23 Nov 2010, at 11:02, Hartmut Reuter <reu...@rzg.mpg.de> wrote: >> >> The problem here ist that afs_DoPartialWrite is called with each write. >> Normally it gets out without doing anything, but if the percentage of dirty >> chunks is to high it triggers a background store. > > On master, at last DoPartialWrite does an immediate store - the only place we > can do a background write is in response to a normal close request. > > In any case, this problem arises regardless of how we're storing the file. > The issue is that our cache eviction strategy picks the most recently > accessed chunk to evict, and then we dirty that chunk again immediately after > we've flushed it. > > We need a better solution to cache eviction. The problem is that, until very > recently, we didn't have the means for one process to successfully flush > files written by a different process.
even at that, we did have the opportunity to try to evict earlier chunks, but things can now get better in head; (and 1.6) -- Derrick _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
