Re: [AVFS] Caching content of extfs archives

Hi,

On 2006-02-15 12:29, Miklos Szeredi wrote:
> You can generate the key from the ventry with av_filecache_getkey().

Yes, I know but my intention was to remove some entries after some time
(say 10 minutes or so) whenever I insert another one. But I neither have
a ventry nor a key for any other entry in the filecache. But on a second
thought it's perhaps not very useful anyway.

> And filecache should be able to remove the cache entries when avfs
> exits: destroy_filecache() will call filecache_delete() which will in
> turn unreference the object held in the cache.  If this was the last
> reference (as should be at exit), then the object's destructor is
> called, where the temporary file can be deleted.

The "filecache" will indeed remove all entries at exit but not the
"cache". In theory the destructor of each filecache object could remove
the associated "cache" entry but I think it's unreliable to access the
"cache" from the destructor of the "filecache" (it could be destroyed
already).

> Using it together with "cache" is a bit convoluted, but "cache" has
> the advantage of managing the disk space used globally within AVFS.

Agreed. I thought about both solutions. It's not possible to find an
entry in the "cache" without the corresponding cacheobj pointer (there's
no function) and the entries are not freed at the exit. On the other
hand the "filecache" doesn't handle disk space issues. So both caches
need to be used but I don't like the cyclic dependency.

> Yes this sounds like a very useful feature.  I think it's OK whether
> you do it with the filecache+cache or your own solution, though the
> former would be slightly better.

Yes, using the cache would be better but the current cache API is not
sufficient. I will implement a proof of concept with additional API
functions and see if it works well enough.

The following problems needs to be solved:
1.The use of the old API should be compatible with the current behavior.
2.The new API should allow accessing entries by name, should not give
out the cacheobj and hold the only reference to it instead (which
violates the statements in "api-overview").
3.The new API will also violate the old API in the mean that removing an
entry from the cache would not immediately free some disk space since as
long as some file is still opened the tmpfile will not be removed.

Basically we would have two caches which maps to the same internal data
structure. This way the user can also clear the cache by accessing
#avfsstat/cache.

What do you think about this solution?

BTW, I just noticed that it would be a good idea to also use this cache
for the urar module (perhaps others) since there are also tmpfiles involved.

Best Regards,

Ralf Hoffmann

-- 
Homepage: http://www.boomerangsworld.de
E-Mail: Ralf Hoffmann <[email protected]>
  english or german







-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642