Hi,
On Mon, 2005-01-24 at 19:27, Alex Tomas wrote:
> oops. i overlooked this line. so, the fix becomes minor improvement patch ;)
Agreed, but a worthwhile one anyway. I'm still worried if you've seen
tests where this patch definitely cured a journal overflow, though ---
if so, it may be masking
> Stephen C Tweedie (SCT) writes:
SCT> /*
SCT>* Be pessimistic here about the number of those free blocks which
SCT>* might be required for log descriptor control blocks.
SCT>*/
SCT> ...
SCT> left -= (left >> 3);
oops. i overlooked this line. so, the fix becomes minor
Hi,
On Mon, 2005-01-24 at 17:47, Alex Tomas wrote:
> SCT> I don't see how that "limit" is relevant here. ...
> if (bufs == ARRAY_SIZE(wbuf) ||
> commit_transaction->t_buffers == NULL ||
> space_left < sizeof(journal_block_tag_t) + 16) {
> Stephen C Tweedie (SCT) writes:
SCT> I don't see how that "limit" is relevant here. wbuf is nothing but the
SCT> size of the IO batches we pass to ll_rw_block() during that commit
SCT> phase. j_free affects the total size of space the *entire* commit has
SCT> to run into, and (as akpm h
Hi,
On Wed, 2005-01-19 at 15:32, Alex Tomas wrote:
> under some quite high load, jbd can hit J_ASSERT(journal->j_free > 1)
> in journal_next_log_block(). The cause is the following:
>
> journal_commit_transaction()
> {
> struct buffer_head *wbuf[64];
> /* If there's no mo
Good day,
under some quite high load, jbd can hit J_ASSERT(journal->j_free > 1)
in journal_next_log_block(). The cause is the following:
journal_commit_transaction()
{
struct buffer_head *wbuf[64];
/* If there's no more to do, or if the descriptor is full,
6 matches
Mail list logo