[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: ext3 fsck question



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






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]