On Fri, Feb 15, 2002 at 11:27:25AM -0800, Andrew Morton wrote: > What happens at present is that recovery can replay data unnecessarily - it > will rewrite transactions which were in fact fully checkpointed at the > time of the crash. > > But addressing this shortcoming would require that the ext3 commit phase > seek to the head of the journal to update the journal superblock each > time we've fully checkpointed a transaction. Which would slow down > normal operation to gain a recovery-time speedup. Which is a bad > tradeoff. > > Possibly we could optimise this by putting additional information into > the journal commit blocks - record the highest known-to-be-committed > transaction ID within the commit block. hmm. That should work, and would be very interesting. We're having to do a two-pass scan over the journal anyway, in order to look for revoked blocks. So going through the commit blocks to find the highest transaction number where all of the blocks are known to be written to their final locations on oxide would be quite doable. > I suggest that you ensure that you're getting the best possible > parallalism in the recovery, and perhaps experiment with smaller > journals. The main problem I'd agree is most likely that the journals aren't being replayed in parallel. - Ted
