On Mon, Oct 18, 2010 at 4:06 PM, Chris Turner <c.tur...@199technologies.org> wrote: > elekktrett...@exemail.com.au wrote: >> >> Suggestions? > > quick-fix / hack wise - > > probably setup some job to run way more often > that checks the status & makes a determination - > or move the job to something like anacron, etc > > although, in a laptop situation - you might want > to manage this manually - because the heavy work > from reblocking, etc could easily suck the juice > out of your battery when you dont want it.. >
Until / unless we have the disk scheduler tuned to a point that we can just run a "prunerandreblockerd" all the time, I think it would be sufficient (and in my opinion, preferred) to simply warn the administrator based on some metric, time since last reblock, egregious amount of storage used by history, low amount of free disk space, etc., or some combination, if it is to be on by default. ... That is, if we do anything at all. I think making it clear in the HAMMER documentation that the periodic maintenance must be performed, and why, should be sufficient. I do not feel that it is terribly obvious right now. That said, I think it would be fine to commit one or more optional stopgap measures/scripts to the RC system, for mobile users and etc., as long as it is well documented that they may go away if a better solution is developed or derived. If there were a consensus, it is possible we could see about getting a script or two written for RC and/or documentation updates made as a part of Google Code-In, if DragonFly is accepted. Assuming there are no volunteers participating in this thread. Sam