On Tue, 2007-05-15 at 19:38 +0100, Matthew Toseland wrote: > On Friday 11 May 2007 08:24, Bob Ham wrote: > > On Thu, 2007-05-10 at 22:20 +0100, Matthew Toseland wrote: > > > On Thursday 10 May 2007 21:38, Bob Ham wrote: > > > > On Thu, 2007-05-10 at 00:36 +0100, Matthew Toseland wrote: > > > > > On Wednesday 09 May 2007 20:28, Bob Ham wrote: > > > > > > That was what I proposed near the start of this thread. I would > > > > > > note, as well, that the store-shrinking code should already exist > > > > > > for cases when the user reduces the configured size of the store. > > > > > > > > > > It does, but as I have already stated at least once, it is difficult > > > > > to efficiently do an online shrink while preserving the most recently > > > > > used data. > > > > > > > > > > It is of course possible. One way to do it is to swap the key you'd > > > > > be deleting with the least recently used key just before truncating. > > > > > > > > What's your point? > > > > > > Obviously the latter is preferred but we can only do it on startup. > > > > I'm still unsure as to why you're telling us this. Is your point that > > work still needs to be done on store shrinking? > > No, it's that dynamically shrinking the cache as the store grows isn't > feasible without additional work on shrinking.
Erm.. it isn't feasible without additional work on itself, either. Your point is completely redundant. No code is feasible without its dependencies. Bob -- Bob Ham <rah at bash.sh>
