GNOME Bugzilla – Bug 552680
simple patch to make thumbnail cleaner less aggressive
Last modified: 2008-09-22 20:58:09 UTC
May I commit this minor tweak to the thumbnail cleaner defaults? I have svn commit access. - Mike
Created attachment 118899 [details] [review] Minor tweaks to thumbnail cleaner defaults
Thanks for your efforts! You may also want to patch gnome-settings-daemon's equivalent in-memory defaults, i.e. inside gsd-housekeeping-manager.c: DEFAULT_MAX_AGE_IN_DAYS DEFAULT_MAX_SIZE_IN_MB I can't judge whether the change is needed, but you also need release team approval: http://live.gnome.org/ReleasePlanning/Freezes#ApprovingFreezeBreaks
Oh, I forgot about the freeze. I'll wait - everyone has different ideas about what the correct values for these parameters are, and I don't really feel like starting a collaborative flamefest today... And yes, the DEFAULT_MAX defaults would be covered in a separate patch. - Mike
I think it's rather important to get inreased schema defaults into 2.24. Since it's not a code change we don't need release team approval. I'd vote for an even higher size limit like 512MB, though. The problem with a low size limit is that for people with a lot of thumbnails (for example due to large collection in f-spot, see bug 551944), we'll start cleaning them out again immediately which is kind of annoying (it might be actually be ok to disable the size limit completely by default, and only check for age, but let's leave that for another time).
*** Bug 551944 has been marked as a duplicate of this bug. ***
180 days and 512 MB are fine with me. But I wouldn't support anything above 512 MB. This didn't really get discussed much earlier, which I guess was a mistake. So... do we need release team approval or not? - Mike
We don't. We just need libgnome maintainer approval.
I'd like to point out that I consider 64 MB totally fine (around 2500 photography thumbnails). In the original thumbnailing bug 523159 comment 37, I suggested to add a thumbnail cleanup inhibition API, so that thumbnails are not removed while they are used by an application.
The problem isn't so much purging thumbnails that applications are currently using (although that could certainly happen as well). The problem is that * you start <photo app>; lots of thumbnails are generated (>limit) * you shut down * you log back in * lots of thumbnails are purged * you start <photo app>; lots of thumbnails are generated - again Adding inhibit API won't help at all. I agree that most people will be fine with 64MB (I am), but it does create problems for people working with lots of images, and we can easily lessen those problems by increasing the limit. Most people will also be fine with a slightly larger thumbnail cache. Basically, for users who don't use thumbnails a lot the cache will only grow slowly, so they are then much more likely to hit the max age than the max size.
It should be mentioned that fspot now checks and increases the max_size parameter on its own, based on its internal database. Which is entirely appropriate, I think. So the most likely source of small-cache complaints has been eliminated. - Mike
While it's nice that f-spot now does this, it's only one among a host of image management apps. I'm not sure making all of them play with our GConf keys is a very pratical solution (and then there are non-Gnome apps, too).
I'm fine with changing the defaults but I still think we need to run this by the release team if we are to get it into 2.24.0. Also there's code changes needed in gnome-settings-daemon as mentioned in comment #2
The code change isn't required if the schemas are properly installed, so we can do that for .1. If you still want to run it by the release team, please do.
Created attachment 119177 [details] [review] schema bump to 180 days / 512 MB
Created attachment 119178 [details] [review] housekeeping bump to 180 days / 512 MB OK, I'm asking release team...
... and they approved. I have committed the new 180 day / 512 MB settings. - Mike
Thanks!