Re: Bug in snapshot?

From: Henrik Nordstrom <hno@dont-contact.us>
Date: Sun, 23 Apr 2000 13:51:28 +0200

Adrian Chadd wrote:

> Hrm. I'll give it a shot. The annoying bit is that when the storeentry
> is to be pulled out, you can't issue an unlink() since the object
> might be in use by something else. So you have to ''fake' it, by
> removing the object from the repl policy manually, then set the
> swap_filen / swap_dirn to -1, then call storeRelease{Request}.
> I tried it quickly but it failed miserably, so I was going to worry about
> it much later.

Sounds like exacly the same issue.

If I remember correctly the key was to first call storeReleaseRequest,
then do what you describe above. Ugly yes, but it works (or at least
worked in Squid-2.2, haven't verified it to 100% in modio).

> Once I have defined an async io model, diskd is only one of the possible
> asyncio mechanisms. Under FreeBSD it'd probably work better to use
> the posix AIO or the kqueue stuff, under Linux it'd probably work better
> to useclone()/threads, under Solaris libaio might bethe best choice ..
> Implementing disk as the underlying mechanism forces me to clean up
> the storage manager and its use of memory first, which isn't a bad
> thing.

This I agree on.

> COSS is a neat idea (thaanks Eric!) and it doesn't have the problem of
> a straight cyclic store.

Eric stole this idea from me ;-) (see the early discussions on
squid-dev, partly archived on my web pages). Thanks Eric for
implementing it.

> It is full of memcpys, limited to 2gb stores
> currently, and is not asyncio ready, but as it was a nice tease for
> the storage io /replacement reorganisation, it will be a nice tease
> for the storage manager memory reorganisation (one of the thing I
> want to do with COSS and UFS is support clustered writes so COSS
> doesn't require a membuf and lots of copying and UFS objects are written
> in chunks larger than DISK_PAGE_SIZE or SM_PAGE_SIZE).

Ok. If you are working on the store memory management, then I'll take a
look into cleaning up the replacement policy management.

/Henrik
Received on Sun Apr 23 2000 - 06:26:23 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:12:23 MST