On Mon, Jun 11, 2001, Sadhna.Ahuja@nokia.com wrote:
> Hi Henrik,
> I understand how the replacement policies work on the in-memory
> objects and StoreEntry's. What I don't understand is how (where in the src
> code) is this situation handled -- Say, I have configured my Squid to use a
> 'cache-dir' of 100MB. All of this has been filled, but none of the content
> has expired, hence not been flushed out by 'swapMaintainSpace'. What happens
> if a new file needs to be opened on the filesystem for new incoming content?
> If my understanding so far is correct, StoreEntry is just a sort of
> index in memory for objects on the disk, and releasing a StoreEntry doesn't
> effect the actual stored object. Am I right?
> >
Nope. If you destroy a StoreEntry, you also destroy the object on disk,
if any.
So, if the store space is running low and space needs to be freed up,
this litle bit of code gets run (example ripped from
src/fs/ufs/store_dir_ufs.c but its the same in aufs/diskd..)
in storeUfsDirMaintain() :
debug(20, 3) ("storeMaintainSwapSpace: f=%f, max_scan=%d, max_remove=%d\n",
f, max_scan, max_remove);
walker = SD->repl->PurgeInit(SD->repl, max_scan);
while (1) {
if (SD->cur_size < SD->low_size)
break;
if (removed >= max_remove)
break;
e = walker->Next(walker);
if (!e)
break; /* no more objects */
removed++;
storeRelease(e);
}
walker->Done(walker);
debug(20, (removed ? 2 : 3)) ("storeUfsDirMaintain: %s removed %d/%d f=%.03f
max_scan=%d\n",
SD->path, removed, max_remove, f, max_scan);
.. which creates a walker and walks through the replacement policy
Purge list until we've either hit max_remove objects, or the current
storedir size is lower than the low_size (the low watermark you've
set).
I hope this clears things up.
adrian
Received on Mon Jun 11 2001 - 08:56:07 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:00:37 MST