On Fri, Sep 2, 2011 at 3:58 PM, Jason Duell <[email protected]> wrote:
> On 08/30/2011 02:49 PM, Michal Novotny wrote: > >> I've been looking into possibilities of solving the problem that we delete >> the cache in case of crash. I'd rather discuss the topic here than bloating >> bug #105843 even more... >> >> As far as I can see, the best solution with the current code would be to >> add a journal file that would keep a track of all dirty blocks, separate >> files and cache map entries that need to be deleted if a crash occurs. From >> time to time we would sync block files and map file to disk and the journal >> file would be cleaned up at this point. The problem is that we would need to >> sync the journal file after every change and regarding the comment #3 in bug >> #681085 I'm not sure that this is acceptable. >> >> Any thoughts on this? >> >> Michal >> > > We could use someone who's familiar with how databases work to think about > this. I'm not that person. > > I'm not suggesting we ape chromium thoughtlessly, but their cache does > recover from crashes w/o using fsync AFAICT--see > > > https://bugzilla.mozilla.org/**show_bug.cgi?id=681085#c6<https://bugzilla.mozilla.org/show_bug.cgi?id=681085#c6> > > We should at least understand their design. FWIW, I fought with this bug a long time ago. I don't remember the exact details, but this whole thing was a huge mess. We have to sync all kinds of flags to disk as the cache is being populated, and that's all I/O, so it could hurt performance, so we should be smart about syncing less often, but that would leave us in inconsistent states, etc. It's basically implementing ACID manually. If you're going to look into this project, I propose that rearchitecturing the cache might be the best option going forward. -- Ehsan <http://ehsanakhgari.org/> _______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
