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

Re: ext3 fsck question



mb/ext3 dcs qmul ac uk wrote:
> 
> Hi,
> 
> After our big ext3 file server crashes, I notice the fsck spends some time
> replaying the journals (about 5-10 mins for all volumes on the server in
> question). I guess it must do this should you want to mount the volumes as
> ext2.

That must be one big server.  Are the fsck's running in parallel?

The ideal situation is that individual partitions on each disk
are fsck'ed sequentially, and that all disks are fsked in parallel.
So you end up with a *single* fsck running against each disk, but
all disks being worked on in parallel.  This is all possible, but
requires some genuflection over fsck and fstab manpages.

Oh, and how come your server crashes?

> My question--is it (theoretically) possible to tell fsck only to replay
> half-finished and to knock out incomplete transactions from the journals,
> leaving the kernel to replay the good ones in its own time, possibly
> reducing downtime by a few minutes? Or might this break assumptions the
> kernel code makes? Or is it totally impossible and ridiculous? :)
> 

No, this is quite possible, but not desirable.

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.

I suggest that you ensure that you're getting the best possible
parallalism in the recovery, and perhaps experiment with smaller
journals.

-





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