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

Re: how to counteract slowdown

Daniel Pittman wrote:
> On Tue, 13 Nov 2001, Andrew Morton wrote:
> > Daniel Pittman wrote:
> [...]
> >> Yes, it would. Now, this latency would happen only if the journal got
> >> to be so full that we couldn't fit more data, right? The code looks
> >> that way (unless the journal is destroyed or the FS remounted, of
> >> course.)
> >
> > Pretty much, yes. I think the problem we're seeing is to do with the
> > fact that once the journal is 1/4 used, we force checkpointing of the
> > in-memory data into the main fs,
> When it's 25% full? That seems ... low to me. I would have expected to
> see that happen at closer to 75%, because then the standard asynchronous
> write-out would be able to close transactions for you for "free" without
> blocking the filesystem.

oops.  When a transaction reaches 25% of the journal size,
we force a commit.

When the journal is 50% to 75% full, we force a checkpoint (that is,
write buffers from earlier transactions out so we can release the
journal space).

> When the journal hits 25% used, start async write-out.
>   -- this should also be the case for the kjournald old data. :)
> When the journal hits 75% used, start sync write-out.
> When the usage drops to 50% (or so), stop the sync write-out but
>    continue the async write-out.

It's sort-of like that now.  At 50%-70% occupancy we do a synchronous
> That way you would hopefully see reasonable performance for short
> workloads up to 75% of the journal size.

Try it - set /proc/sys/fs/jbd-debug to 2 and send increasingly
large writes into the journal.  See at what size "Handle %p waiting for
checkpoint...: comes out.

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