Re: [AVFS] Caching content of extfs archives

> > 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.

OK, I see.

> > 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).

It should be OK.  Look at filt_newnode() in filter.c.

> > 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?

So you basically want to unify 'cache' and 'filecache'?  That makes
sense, since the current interface is quite difficult to use.

> 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.

Yes.

Thanks,
Miklos


-------------------------------------------------------
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